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I.  INTRODUCTION 


A.  BACKGROUND 

Generally  accepted  knowledge  indicates  that  the  U.S.  Marine  Corps  system  for 
soliciting  and  staffing  reserve  billets  is  relatively  fractured,  redundant,  geographically 
dispersed  and  inefficient  for  administrators  and  users.  This  research  was  conducted  to 
assist  the  Marine  Corps  Manpower  Information  Technology  (MIT)  branch  at  the 
Manpower  and  Reserve  Affairs  (M&RA)  department  of  Headquarters  Marine  Corps.  A 
systems  analysis  was  conducted  to  create  an  improved  billet  advertisement  system  for  the 
Marine  Corps  Reserve,  including  identifying  system  requirements,  developing  a  logical 
generic  architecture,  and  providing  a  proposed  system  architecture  for  improving  the 
system. 

B.  OBJECTIVES 

The  current  system  called  Reserve  Duty  Online  (RDOL)  was  meant  to  be  a  one- 
stop  location  for  Reservists  to  look  for  and  apply  for  different  billets  available  for 
reservists  to  fill  in  support  of  the  Marine  Corps  [1].  Funding  shortfalls  and  organizational 
buy-in  issues  contributed  to  a  system  often  referred  to  as  fractured  and  lacking  in  the 
functionality  needed  to  meet  the  objectives  of  the  system. 

This  thesis  provides  the  Marine  Corps  with  a  “roadmap”  or  outline  to  replace 
RDOL.  The  roadmap  is  comprised  of  a  detailed  systems  analysis,  a  generic  architecture, 
logical  data  models  and  process  models  which  provide  the  Marine  Corps  with 
documentation  to  develop  a  new  system  of  record. 

A  secondary  outcome  of  this  thesis  was  to  analyze  current  system  architectures 
that  advertise  and  fill  Department  of  Defense  (DoD)  job  vacancies,  including  analyzing 
commercial-off-the-shelf  (COTS)  products.  The  goal  was  to  determine  the  extent  to 
which  alternative  architectural  attributes  can  be  leveraged  by  the  Marine  Corps  to  build 
its  next  generation  system.  Desirable  attributes  were  incorporated  into  the  design  of  the 
generic  architecture. 
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C.  RESEARCH  QUESTIONS 

The  following  are  the  main  research  questions  addressed  in  this  thesis: 

1 .  What  is  the  efficacy  of  the  current  technological  process  whereby  the  Marine 
Corps  solicits  and  staffs  billets  to  existing  reservists,  i.e.,  how  well  is  Reserve  Duty 
Online  (RDOL)  working? 

2.  To  what  extent  can  emerging  methodologies  and  technologies  be  used  to 
fundamentally  improve  the  overall  process? 

3.  What  does  a  generic  architecture  of  an  ideal  billet  advertisement  system  look 

like? 

D.  SCOPE 

The  scope  of  the  thesis  encompasses  how  the  Marine  Corps  currently  publishes 
and  processes  reserve  billets  through  the  Reserve  Duty  Online  (RDOL)  web-enabled 
application,  including  recommendations  for  future  system  iterations.  Within  the  context 
of  this  domain,  the  handling  and  utilization  of  member’s  resumes  and  applications  was 
also  examined.  The  thesis  does  not  address  how  applications  and  resumes  are  utilized  in 
the  order  writing  process,  but  does  address  systems  interface  issues. 

E.  METHODOLOGY 

This  thesis  subscribed  to  a  bottom-up  approach  which  focused  on  the  lowest  level 
components  first  to  discover  the  requirements  of  the  system.  The  requirements  were  then 
used  to  build  the  logical  models  that  are  presented  to  the  Marine  Corps  for  use  in  the 
design  of  its  next  system.  To  accomplish  this  strategy,  the  following  two  methodologies 
were  used  to  analyze  how  the  Marine  Corps  advertises  and  solicits  reserve  billets: 

1 .  Framework  for  the  Application  of  Systems  Thinking  (FAST) 

2.  Architecture  Tradeoff  Analysis  Method  (AT AM) 

From  each  of  these  methodologies,  a  subset  of  prescribed  steps  applicable  to  the  topic 
domain  was  utilized.  These  “subsets”  were  synthesized  and  juxtaposed  to  form  a  hybrid 
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methodology  used  to  address  the  Marine  Corps  problem  domain.  The  following  is  a  brief 
introduction  to  each  methodology  and  the  steps  that  were  used. 

1.  Framework  for  the  Application  of  Systems  Thinking  (FAST) 

FAST  is  a  hypothetical  methodology  introduced  in  the  text,  Systems  Analysis  and 
Design  Methods  by  Jeffery  L.  Whitten  and  Lonnie  D.  Bentley  [2].  Even  though  the 
methodology  is  labeled  “hypothetical”,  it  still  contains  feasible  and  practical 
methodologies  applicable  for  problem  solutions.  In  short,  it  is  an  iterative  and  inclusive 
approach  constructed  of  industry  best  practices.  Its  structure  also  allows  the  analysis  to  be 
responsive  and  flexible  to  different  inputs  and  requirements.  Model  flexibility  is  crucial 
due  to  the  breadth  of  input  provided  by  system  stakeholders  and  owners. 

FAST  is  an  eight  phase  process,  of  which  the  following  four  phases  were  utilized: 
scope  definition,  problem  analysis,  requirements  analysis  and  logical  design.  Each  phase 
is  iterative  producing  results  and  milestones  documented  in  the  next  phase.  Listed  below 
is  a  brief  discussion  of  the  composition  of  each  phase  and  the  deliverables  for  each  phase. 

1 .  Scope  Definition:  The  purpose  of  this  phase  is  to  determine  if  the  problem  is 
worthwhile,  as  well  as,  determining  if  the  breadth  of  the  scope  is  within  the  realm  of 
possibility.  Deliverables  for  this  phase  include  a  detailed  problem  statement  and 
identification  of  constraints. 

2.  Problem  Analysis:  This  phase  examines  the  existing  systems  and  their 
interactions.  The  results  of  the  analysis  provide  designers  with  an  understanding  of  the 
current  system  and  its  problems.  From  this  understanding,  business  requirements  and 
criteria  are  defined  which  are  used  as  the  basis  for  Measures  of  Effectiveness  (MOE) 
used  to  evaluate  the  system. 

3.  Requirements  Analysis:  This  phase  detennines  what  the  system  should  do,  as 
well  as  defining  and  prioritizing  business  requirements.  Specifically,  this  phase  defines 
system  functionality,  data  needing  to  be  captured  and  stored  and  system  capabilities.  This 
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phase  does  not  define  technical  specifications;  rather  it  defines  and  prioritizes  business 
requirements.  The  completed  deliverable  is  a  Business  Requirements  Document  for 
modeling  the  new  system. 

4.  Logical  Design:  This  phase  converts  business  requirements  into  a  systems 
model.  The  systems  model  is  used  to  ensure  completeness  and  to  identify  missing 
functionalities  or  data  requirements.  This  phase  generated  Logical  Data  Models  and 
Logical  Process  Models. 

2.  Architecture  Tradeoff  Analysis  Method  (AT AM) 

ATAM  is  an  architectural  evaluation  methodology  presented  in  Evaluating 
Software  Architectures:  Methods  and  Case  Studies  by  Paul  Clements,  Rick  Kazman  and 
Mark  Klein  [3],  This  methodology  focuses  on  how  well  architecture  addresses  the 
quality  attributes  or  goals  required  by  stakeholders.  It  also  provides  an  understanding  on 
how  different  quality  attributes  or  goals  interact  with  each  other.  ATAM  was  chosen 
because  it  is  a  proven  method  providing  needed  structure  during  the  architectural  analysis 
process.  This  structure  helps  ensure  that  all  system  requirements  are  identified.  Both  of 
these  characteristics  make  this  methodology  ideal  for  this  problem  domain,  as  they 
address  a  known  RDOL  core  deficiency:  a  lack  of  understanding  of  stakeholder 
requirements. 

The  ATAM  is  a  nine  step  process  that  investigates  how  well  an  architecture  that  is 
chosen  and  designed  satisfies  a  particular  set  of  quality  goals,  and  it  provides  insight  on 
how  well  the  quality  goals  identified  interact  with  each  other  [3].  The  nine  steps  of  the 
ATAM  are:  (1)  the  ATAM  is  presented  to  the  client;  (2)  business  drivers  are  identified 
and  presented;  (3)  the  architect  presents  the  architectural  methodology;  (4)  the  architect 
identifies  architectural  approaches  for  addressing  the  problem  domain;  (5)  the  architect 
generates  a  quality  attribute  utility  tree;  (6)  the  architect  analyzes  the  different 
architectural  approaches;  (7)  the  architect  creates  scenarios  used  to  test  the  architecture 
against  the  quality  attributes;  (8)  the  architect  evaluates  the  architectures  using  the 
scenarios  generated;  and  (9)  the  architect  presents  and  explains  the  results  [3].  These 
nine  steps  are  presented  in  Figure  1,  and  are  divided  into  the  following  four  functional 
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groups:  presentation  group,  investigation  and  analysis,  testing  and  reporting  group.  Of 
the  nine  steps,  four  through  eight  were  used.  Steps  one  through  three  was  not  utilized 
because  the  requirements  dictated  in  each  of  the  steps  were  completed  by  a  phase  in  the 
FAST  methodology.  Step  nine’s  requirements  are  incorporated  into  thesis  conclusions. 


Presentation 

Investigation  & 

Analysis 

Testing 

Reporting 

1.  Presentation  of 

ATAM 

4.  Identify  the 

architectural 

approaches 

7.  Brainstorm  and 

prioritize 

scenarios. 

9.  Present  the  results 

2.  Presentation  of 

Business  Drivers 

5.  Generate  the 

quality  attribute 

utility  tree 

8.  Analyze  the 

architectural 

approaches  using 

scenarios 

3.  Presentation  of 

6.  Analyze  the 

Architecture 

architectural 

approaches 

Figure  1 .  Steps  of  the  ATAM 


We  began  the  tradeoff  analysis  with  the  identification  of  architectures.  This  step 
correlates  to  step  four  of  the  nine  step  process  introduced  earlier.  Within  this  step  the 
different  architectural  approaches  or  styles  are  identified  but  not  analyzed.  Each 
architectural  style  describes  the  component  types  and  their  topology,  and  describes  how 
data  is  patterned  and  controlled  [3].  During  this  step  the  best  architecture  for  this 
problem  domain  is  identified,  including  pros  and  cons  of  relevant  styles.  The  point  is  to 
gain  an  increased  understanding  of  the  strengths  and  weaknesses  of  the  high  level 
architecture  model,  including  providing  a  baseline  for  subsequent  analysis. 

Step  five  generates  a  quality  attribute,  four-node  tree  (qatree)  which  identifies, 
prioritizes,  and  refines  important  quality  attribute  goals.  Leveraging  this  tree  is  meant  to 
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capture  stakeholder  requirements.  The  first  level  of  the  tree  is  the  “utility”  apex.  The 
second  level  identifies  the  quality  attributes  for  the  system  which  are  further  refined  on 
the  third  level.  The  forth  level  (the  leaves)  prioritize  specific,  quality  attribute 
requirements  [3].  These  “fourth  level  requirements”  are  presented  in  the  form  of 
scenarios  which  are  used  to  evaluate  the  validity  of  the  architecture  being  proposed. 
These  scenarios  are  used  and  refined  in  steps  six  through  eight  to  prioritize  and  select  the 
most  desirable  architectural  solution. 

F.  ORGANIZATION  OF  STUDY 

The  remainder  of  this  thesis  is  organized  as  follows: 

Chapter  II  provides  an  overview  of  the  Marine  Corps  Reserve,  how  billets  are 
currently  solicited  and  staffed,  and  an  analysis  of  current  RDOL  problems.  Chapter  III 
describes  and  outlines  the  methodologies  employed  during  the  architectural  design  and 
systems  analysis.  Chapter  IV  identifies  and  analyzes  current  architectural  designs  that 
may  provide  the  framework  from  which  the  next  system  can  be  designed.  Chapter  V 
presents  the  architectural  vision,  validated  through  use  of  scenarios.  Chapter  VI  ties  the 
results  of  the  systems  analysis  to  the  generic  architecture  presented  in  Chapter  V. 
Specifically,  the  data  captured  during  the  systems  analysis  was  used  to  build  the  process 
and  logical  models,  which  are  presented  with  their  corresponding  generic  components. 
Chapter  VII  summarizes  the  study  providing  conclusions,  recommendations  and  areas  for 
future  research. 
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II.  MARINE  CORPS  RESERVE  AND  CURRENT  SOLICITATION 

METHODS 


A.  BACKGROUND 

Due  to  the  wartime  operational  tempo  throughout  the  Marine  Corps,  an  increasing 
demand  has  been  and  will  continue  to  be  placed  on  the  Marine  Corps  Reserve,  which  has 
made  an  extraordinary  contribution  both  here  at  home  and  abroad.  The  importance  of 
placing  reserve  Marines  into  appropriate  billets  is  critical  because  they  provide  essential 
support  and  augmentation  of  the  active  component  of  the  Marine  Corps.  Getting  the  right 
Marine  in  the  right  position  in  a  timely  manner  in  a  wartime  environment  is  paramount. 
This  chapter  discusses  the  history,  background,  and  current  status  of  the  way  in  which  the 
Marine  Corps  solicits  and  staffs  various  types  of  reserve  billets. 

1.  Marine  Corps  Reserve 

As  of  May  2007,  the  Marine  Corps  Reserve  is  comprised  of  over  33,359  Marines 
in  Selected  Marine  Corps  Reserve  (SMCR)  drilling  reserve  units  from  across  America 
and  Puerto  Rico,  over  2,576  Individual  Mobilization  Augmentees  (IMA),  2,211  Active 
Reserves  (AR),  and  nearly  60,000  Individual  Ready  Reserve  (IRR)  Marines.  This  is  the 
pool  of  capabilities  drawn  upon  to  augment  the  SMCR  or  Active  Component  (AC)  [4]. 
For  the  past  six  years  the  Marine  Corps  Reserve  Component  has  augmented  and 
reinforced  the  Active  Component  in  support  of  the  Global  War  on  Terror.  As  of  March 
2007,  41,560  Reserve  Marines  have  been  mobilized  since  1 1  September  2001  [5]. 

2.  Types  of  Marine  Corps  Reservists 

The  Marine  Corps  Reserve  is  composed  of  the  Ready  Reserve,  which  includes  the 
Selected  Marine  Corps  Reserve  (SMCR)  and  the  Individual  Ready  Reserve  (IRR),  the 
Standby  Reserve,  and  the  Retired  Reserve.  Figure  2  depicts  the  types  of  reserve 
categories  in  the  Marine  Corps  Ready  Reserve.  A  brief  description  of  each  follows. 
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Figure  2.  Marine  Reserve  Types 


The  largest  group  is  the  Individual  Ready  Reserve  which  consists  of  Marines  in 
the  Ready  Reserve  not  affiliated  with  the  SMCR  who:  (1)  have  not  completed  their 
Mandatory  Service  Obligation  (MSO);  or  (2)  have  completed  their  MSO  and  are  in  the 
Ready  Reserve  by  voluntary  agreement;  or  (3)  have  not  completed  their  MSO  (are 
mandatory  participants),  but  are  transferred  to  the  IRR  during  unique  situations  [6]. 

The  second  largest  group  in  the  Marine  Corps  Reserve  is  the  Select  Marine  Corps 
Reserve  (SMCR).  SMCR  units  are  located  in  187  Reserve  training  centers  across 
America  and  consist  of  more  than  17,500  Reserves  from  4th  Marine  Division  (4th 
MARDIV);  8,500  from  4th  Marine  Logistics  Group  (4th  MLG);  8,000  from  4th  Marine 
Aircraft  Wing  (4th  MAW).  Members  of  the  SMCR  typically  drill  one  weekend  per 
month,  and  attend  two  weeks  of  annual  training  (AT)  [4], 

Individual  Mobilization  Augmentees  (IMA)  are  Marines  that  are  members  of  the 
SMCR,  but  are  not  members  of  a  drilling  SMCR  unit.  The  IMA  program  provides  a 
source  of  trained  and  qualified  individuals  to  fill  individual  billets  which  augment  the 
active  component  structure  of  the  Marine  Corps,  Department  of  Defense  (DOD)  or  other 
Departments  or  Agencies  of  the  Government.  IMA  Marines  fill  billets  contained  on 
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Active  Component  Tables  of  Organization  (T/O)  and  upon  mobilization  continue  to 
perform  the  same  type  of  duty  that  they  do  when  they  are  drilling  [7]. 

Active  Duty  Operational  Support  (ADOS),  which  was  formally  known  as  Active 
Duty  Special  Work  (ADSW),  is  designed  to  provide  the  Marine  Corps  a  means  to  utilize 
Reserve  personnel  of  appropriate  grades  and  skills,  through  short  tours  of  active  duty,  to 
provide  personnel  augmentation  for  both  Active  and  Reserve  forces  to  accomplish  special 
projects,  and  to  meet  operational,  administrative,  and  exercise  support  requirements  of  a 
temporary  duration.  It  provides  opportunities  for  Reserve  Marines  in  the  SMCR  and  IRR 
to  support  short-term  requirements,  special  projects,  exercise  support  participation  for 
both  the  Active  and  Reserve  forces.  ADOS  Marines  are  assigned  to  major  Marine  Corps 
bases  and  stations,  headquarters,  and  reserve  unit  locations  as  needs  are  identified  by 
Operational  Sponsors  [8]. 

The  Active  Reserve  (AR)  program  consists  of  Reserve  officers  and  enlisted 
Marines  who  serve  in  selected,  full-time  active  duty  billets.  The  primary  mission  of  AR 
Marines  is  to  support  the  organization,  training,  retention,  and  administration  of  the 
Marine  Corps  Reserve.  The  AR  program  allows  Marines  an  opportunity  to  serve  on 
active  duty  and  qualify  for  retirement  benefits  after  20  years  of  service  [9]. 

The  Reserve  Counterpart  Training  (RCT)  program  is  designed  to  provide 
members  of  the  IRR  an  opportunity  to  improve  military  skills  by  training  with  their 
Active  Component  counterparts.  This  program  enables  members  of  the  IRR,  an 
opportunity  to  volunteer  annually  for  assignments  to  Active  Duty  Training  (ADT)  at 
designated  AC  commands  or  for  Annual  Training  (AT).  The  program  is  specifically 
designed  to  upgrade  and  maintain  MOS  and  technical  skills  considered  essential  upon 
mobilization  [10]. 

B.  CURRENT  SOLICITATION  PROCESS 

The  current  manner  in  which  the  Marine  Corps  solicits  and  staffs  reserve  billets 
utilizes  various  methods  including  website  advertisement  via  Reserve  Duty  Online 
(RDOL),  word  of  mouth,  and  hastily  posted  spreadmarts.  A  spreadmart  refers  to  a 
situation  where  spreadsheets  containing  valuable  corporate  data  are  duplicated 
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uncontrollably  and  modified  differently  by  different  users  producing  a  situation  where 
each  file  presents  a  different  version  of  the  "truth"  [11].  RDOL  was  originally  designed  to 
be  the  primary,  required  method  to  advertise  vacant  reserve  billets.  As  noted  earlier,  the 
goal,  ultimately,  was  to  make  RDOL  the  “one-stop”  web  portal  where  reservists  were 
able  to  not  only  search  and  apply  for  different  types  of  reserve  billets,  but  also  receive 
career  guidance  as  well.  Specifically,  the  designers  of  RDOL  envisioned  that  the  site 
would  provide  access  to  valuable  career  information  that  could  be  leveraged  by  reservists 
to  dynamically  manage  their  career  and  maximize  their  utility  for  the  Marine  Corps.  But, 
as  depicted  in  Figure  3,  poor  design  and  lack  of  funding  has  left  the  application  missing 
many  required  user  functionalities,  which  has  led  to  an  apparent  decrease  in  use  and 
further  deterioration  of  the  system.  Many  organizations  publish  vacant  billets  on  their 
own  websites  vice  on  RDOL.  A  quick  web  survey  in  February  2008,  found  that  the  two 
largest  Marine  Corps  Reserve  websites  (Marine  Forces  Reserve/Marine  Corps 
Mobilization  Command)  have  resorted  to  advertising  reserve  billets  themselves.  To 
further  emphasize  this  point,  the  results  of  a  functionality  assessment  conducted  in 
September  2006  by  infoReliance  found  that  RDOL  usage  has  dropped  significantly  since 
August  2005  and  was  attributed  to  an  overall  lack  of  awareness  of  the  site  itself  [1]. 
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1.  Problems  with  Current  Systems 

RDOL  problems  can  be  divided  into  front-end  problems  and  back-end  problems. 
The  front  ends  of  information  systems  support  business  functions  extend  out  to 
organizational  customers  [2].  Currently  RDOL’s  front-end  user  interface  is  not  intuitive 
and  lacks  in  functionality.  The  poorly  designed  user  interface  encourages  end-users  to 
revert  to  alternative  methods  of  accomplishing  tasks.  The  following  are  some  specific 
examples  of  critical  functionality  missing  from  the  front-end  of  the  RDOL  current 
iteration: 

a.  The  search  page  contains  several  redirects  to  other  sites  that  takes  the  user 
away  from  the  principal  reserve  billet  search  page  with  no  way  to  navigate  back  to  it. 

b.  Standard  search  functionality  does  not  allow  the  ability  to  sort  the  results 
of  a  search. 

c.  Some  of  the  advertised  functionalities  are  non-operational.  For  example, 
the  distance  search  function  does  not  work. 

d.  There  are  numerous  redundant  applications  within  RDOL  that  make  the 
site  inefficient  and  cumbersome. 

e.  There  is  no  ability  for  operational  sponsors  to  seek  out  potential 
candidates  to  fill  vacant  billets. 

f.  Reservists  are  unable  to  post  their  reserve  qualification  summary 
(resumes)  for  sponsors  to  analyze. 

The  back  end  of  an  information  system  supports  the  internal  business  operations 
of  an  organization  and  its  suppliers  [2].  In  its  current  form,  RDOL  is  a  stovepipe  system 
isolated  from  other  Marine  Corps  computer  resources  having  a  limited  capability  to 
communicate  with  external  resources. 

The  system  also  lacks  required  basic  functionality  that  users  require  making  the 
system  unproductive.  Some  specific  examples  of  current  back-end  problems  include: 


11 


a.  The  design  of  the  system’s  data  storage  and  data  manipulation 
infrastructure  is  inadequate.  This  has  led  to  dirty  data  being  proliferated  throughout  the 
various  databases. 

b.  In  its  current  iteration,  RDOL  is  missing  significant  interoperability  and 
automation  quality  attributes.  For  example,  all  TFSMS  data  is  hand-entered  by  personnel 
from  Reserve  Affairs. 

c.  The  system  has  a  very  limited  ability  to  communicate  or  integrate  with  any 
other  systems.  Currently  all  personnel  and  table  of  organization  (unit  information)  has  to 
be  manually  entered  into  the  system,  but  the  system  does  transmit  leads  to  prior  service 
recruiters  via  the  Automated  Leads  Management  Reporting  System  (ALMRS). 

The  previous  two  lists  are  not  all  encompassing.  There  are  additional  system 
problems,  but  the  lists  do  capture  a  flavor  of  the  inefficiencies.  Many  of  these  problems 
may  be  attributed  to  ad  hoc,  incremental  process  through  which  the  system  was  built, 
evidently  with  no  architectural  plan  or  useful  framework.  Figure  4  is  provided  as  a 
descriptive  summary  of  system  incongruence’s. 
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Figure  4  depicts  the  current  inefficient  configuration  of  the  Marine  Corps  Billet 
Advertisement  System.  No  known  architecture  exists  for  the  RDOL  system,  and  the 
various  enterprise-level  systems  cannot  communicate  with  each  other,  e.g.,  multiple 
systems  have  no  way  to  share  or  leverage  applicable  resources  resulting  in  substantial 
amounts  of  rework,  duplication  and  user  frustrations. 
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III.  DEPARTMENT  OF  DEFENSE  RESERVE  RECRUITMENT 

PROCESSES  AND  SYTEMS 


In  order  to  ensure  that  the  variety  of  best  practices  available  are  captured,  other 
Department  of  Defense  reserve  recruitment  processes  were  analyzed,  including  an 
examination  of  the  Air  Force’s  Volunteers  in  Professional  Service  (ViPS),  the  Navy’s 
APPLY  system,  and  lastly  Monster  government  solutions. 

A.  AIR  FORCES  VOLUNTEER’S  IN  PROFESSIONAL  SERVICE  (VIPS) 

In  the  spring  of  2005,  the  Air  Force  Reserve  established  a  Volunteer  Process 
Working  Group  and  Integrated  Process  Team  (WG/IPT)  in  order  to  improve  the  process 
of  matching  reservist  volunteers  to  employment  opportunities.  One  of  the  main  focuses 
of  this  working  group  was  to  evaluate  and  analyze  potential  candidate  solutions  for  a 
future  system.  The  main  objective  was  to  focus  on  capturing  the  functional  requirements 
in  order  to  develop  a  volunteer  matching  system  prototype.  In  October  2005,  the  Air 
Force  Reserve  contracted  Science  Applications  International  Corporation  (SAIC)  to  assist 
the  WG/IPT  in  formally  detailing  requirements  and  help  with  the  examination  of 
potential  candidate  solutions  [12]. 

1.  VIPS  System  Functionality 

Many  of  the  processes  within  the  ViPS  program  are  currently  fully  functional 
within  RDOL.  Instead  of  covering  every  function  of  the  ViPS  program,  the  following 
section  will  examine  the  useful  processes  within  ViPS  that  could  be  particularly  useful 
for  RDOL.  Although  there  are  hundreds  of  processes  in  both  ViPS  and  RDOL,  this 
section  will  discuss  those  found  to  be  of  the  greatest  utility.  Each  of  the  processes  is 
listed  by  functional  area  (Reservist,  Employer,  Manager,  and  Administrator). 

2.  VIPS  Features  for  Reservists 

The  Air  Force  ViPS  web  application  has  brought  together  every  type  of  reserve 
opportunity  and  has  truly  created  a  “one-stop-shop”.  In  addition  to  being  able  to  view 
volunteer  assignment  opportunities,  a  ViPS  user  has  the  ability  to  submit  their  profile  for 
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consideration  to  multiple  job  postings,  apply  to  volunteer  for  billets  (Figure  5),  and  even 
coordinate  chain  of  command  approval  if  necessary. 
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Figure  5.  ViPS  Application  Form 


One  function  that  is  highly  desired  in  RDOL  is  the  ability  to  manage  an  electronic 
Reserve  Qualification  Summary  (RQS)  with  data  populated  from  MCTFS  and  free  text 
blocks  [13].  As  noted  in  Figure  6,  the  reservist  has  the  ability  to  manage  their  profile  by 
adding  the  following  information:  preferred  AFSC,  which  is  analogous  to  a  Military 
Occupational  Specialty  (MOS),  assignment  duration,  assignment  location,  dates 
available,  and  if  they  wish  to  receive  solicitations  from  organizations. 
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Sot  your  volunteer  preferences  in  the  form  below  The  ViPS  system  wtH  use  this  information  to  identify  potential  volunteer 
opportunities  that  you  may  be  interested  in 


||  Contact  lit _ S*  cutty  jnd  Privacy  Notiot 


Figure  6.  ViPS  Profile  Page 


The  user  friendly  dashboard  is  another  useful  benefit  that  automatically  notifies 
the  user  of  new  opportunities  and  events  as  seen  in  Figure  7  each  time  he/she  logs  in. 
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Security  and  Privacy  Notice 


Figure  7. 


User  Dashboard 


One  great  additional  feature  is  the  ability  to,  “Email  to  a  Friend”  function  that 
allows  a  user  to  email  a  posting  to  another  member  of  the  reserves.  Even  in  our  high  tech 
world  of  web  marketing  with  banners  and  scripts,  word-of-mouth  still  remains  one  of  our 
most  powerful  tools,  which  this  feature  allows  us  to  leverage. 

3.  VIPS  Features  for  Employers 

Similar  to  Operational  Sponsors/Billet  Managers  utilized  in  the  Marine  Corps 
Reserve  billet  process,  ViPS  divides  the  category  of  employer  into  requisitioner  and 
broker.  The  requisitioner  is  more  of  a  basic  role  that  performs  queries  and  does  the  initial 
input  of  the  billet;  the  broker  on  the  other  hand  is  usually  a  program  manager  that  has 
greater  roles  than  the  requisitioner.  Requisitioners  can  manage  all  active  Volunteer 
opportunities  and  create  new  ones  with  an  easy  to  use  dashboard  interface.  (Figure  8) 
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1  Opportunity  ID 

AFSC 

Location 

Grado 

Duration 

Expiration  Date 

U  of  Applications  1 

VP05223 

3A051 

Baghdad  Iraq 

05  -  06 

179  days 

01  Apr  06 

2 

VP04556 

31P 

Baghdad.  Iraq 

05-06 

179  days 

01  Mar  06 

0 

VP04327 

1N171 

Baghdad.  Iraq 

E5-E6 

120  days 

15  Fob  06 

1 

VP04212 

1N151 

Baghdad.  Iraq 

AtC-TSGT 

120  days 

10  Fob  06 

2 

III  I  I  II  ■ 

►  Keys  to  creating  effective  Solicitations. 

►  Overview  of  the  Chain  of  Command  Approval  Process. 

►  What  can  an  AFRC  Broker  do  for  you? 


Contact  Us  Security  and  Privacy  Notice 


Figure  8.  Requisitioner  Dashboard 


These  added  roles  include:  facilitating  the  resolution  of  non-conforming 
applications  and  validating  the  approval  for  volunteer  applicants.  Similarly  to  RDOL, 
ViPS  allows  the  ability  to  advertise  volunteer  opportunities  to  the  reserve  community,  but 
more  importantly,  it  allows  billet  managers  to  identify  qualified  reservists  to  fill 
vacancies  through  queries  of  profiles  posted  by  the  reserve  members.  Furthermore,  it 
also  contains  easy  to  use  Template-based  opportunity  entry,  a  user-friendly  dashboard 
interface  to  manage  requisitions  and  candidates.  Another  valuable  benefit  of  ViPS  is  the 
automated  email  to  solicit  candidates  and  automated  notifications  to  candidates  informing 
them  of  new  billets. 
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4.  VIPS  Features  for  Managers  (Approval  Authorities) 

Currently  RDOL  does  not  allow  for  the  ability  for  a  reservist  to  apply  for  a  billet 
or  submit  any  type  of  application.  One  great  benefit  in  place  in  ViPS  is  the  ability  for 
approval  authorities  to  route  requests  through  the  chain-of-command  for 
approval/disapproval  (Figure  9). 


VTps 


Volunteers  In  Professional  Service 
^  rovel  Request  Mv  Approval  Hi 


v  /  ” 

AIR  FORCE  RESERVE 


ViPS  Approval  Workflowlnbox 


Volunteer  Approval  Request  for  Col  Bruce  Wilson.  403  Wng  Please  respond  by  09  Feb  06 


Volunteer  ID 
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ID  Duration  Voluntoor  Datos 
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01  Mar  06 -30  Mar  06 


Volunteer  Location 


Nelhs  AFB  NV 


DESCRIPTION: 

PERFORM  DUTIES  ENCOMPASSING  THE  3A  CAREER  FIELD  TO  INCLUDE.  BUT  NOT  LIMITED  TO:  MAINTAIN  AND  UPDATE  FILES 
AND  FILE  PLAN.  TRACK  STATUS  OF  EPR  S  AND  DECORATIONS  AND  PERFORM  WORKGROUP  MANAGEMENT  DUTIES  SECRET 
CLEARANCE  REQUIRED 


Sapt  Nancy  Mills 
Mr  Stan  Todds 


Supervisor 

LRO 


26  Jan  06 
25  Jan  06 


proved 

proved 


Approval  Comments: 


Location 

Duration 

Dates 

VP06115 

Ncili  AFB 

15  days 

01  Jun  05  - 

1 5  Jun  05 

VP02945 

Nein  AFB 

30  days 

12  Nov  05  -  * 

Jan  oo 

Security  and  Privacy  Notice 


Figure  9.  Approval  Process  in  ViPS 


Typically  the  request  will  be  routed  via  system  generated  emails  with  links  for  the 
approver  to  login  to  the  system  to  approve  or  deny.  Additionally,  once  a  candidate  has 
been  approved  for  a  billet,  the  system  automatically  modifies  the  users  profile  in  order  to 
“black  out”  the  candidates  dates  of  availability.  Managers  also  have  a  greater  amount  of 
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visibility  in  the  system  pipeline  through  the  personalized  management  dashboard 
interface  which  allows  them  to  see  a  broad  view  of  their  potential  reservists,  applicable 
billets,  and  application(s)  status. 

5.  VIPS  Features  for  Administrators 

Similar  to  the  members  of  the  Marine  Corps’  Career  Management  Team  (CMT), 
ViPS  administrators  are  responsible  for  configuration  of  the  system  and  its  ongoing 
maintenance  including  establishing  roles  and  access  privileges,  generating  and 
distributing  reports,  and  perfonning  general  help  desk  functions.  Unique  to  ViPS  is  the 
ability  of  the  administrator  to  configure  and  post  employment  surveys,  adjust  the 
searching  agent,  and  ability  to  automatically  detect  “stale”  profiles.  One  great  feature  in 
ViPS  is  the  ability  of  the  administrator  to  adjust  the  volunteer  and  opportunity  matching 
agents  (search  by  volunteer  profile  or  search  by  opportunity  profile)  which  can  be 
configured  by  the  administrator  to  assign  weights  to  specific  fields  to  enable  accurate 
search  results  (e.g.,  AFSC  =  .25,  Available  Date  Range  =  .15,  Location  =  .20,  etc.). 
Moreover,  it  can  be  configured  to  automatically  detect  expired  or  "stale"  volunteer 
profiles  and  allow  the  administrator  to  deactivate  or  archive  and  automatically  notify  the 
volunteer  (email). 

6.  VIPS  Conclusions 

Unlike  RDOL,  ViPS  has  carried  a  significant  amount  of  funding  behind  it,  and 
was  given  a  thorough  requirements  analysis.  Over  the  past  three  years,  the  Air  Force 
Reserve  has  worked  diligently  on  developing  ViPS.  Moreover,  ViPS  is  truly  a  “one-stop- 
shop”  for  a  reservist  seeking  employment  in  the  Air  Force  Reserve.  As  the  Air  Force 
owns  all  of  the  source  code  for  the  ViPS  program,  future  work  could  be  conducted  by  the 
Marine  Corps  to  address  the  potential  of  porting  ViPS  to  become  a  Marine  Corps  web- 
enabled  application.  Although  some  modifications  would  be  required  due  to  differences 
in  our  personnel  systems,  the  basic  functions  of  advertising  reserve  billets  remains  the 
same.  This  could  potentially  save  the  Marine  Corps  a  tremendous  amount  of  money  and 
will  be  discussed  further  in  the  future  work  section  of  this  thesis. 
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B.  NAVY’S  JOAPPLY  SYSTEM 

One  of  the  Navy’s  overarching  goals  is  to  maximize  the  readiness  of  the  fleet  by 
ensuring  that  its  sailors  are  appropriately  trained  and  that  their  skills  honed  and  leveraged 
by  ensuring  that  sailor’s  career  track  is  closely  aligned  to  the  goals  of  the  Navy.  The 
Navy  manages  this  process  by  providing  sailors  with  dynamic  and  comprehensive  set  of 
career  management  tools  to  ensure  that  they  meet  the  appropriate  milestones  in  order 
maximize  their  career  potential.  The  Naval  Reserve  career  management  tools  are 
comprise  of  a  three  tiered  system  that  addresses  different  segments  of  sailors  within  the 
Naval  Reserve  [14]. 

The  first  system  of  the  triad  is  titled  APPLY.  APPLY  is  a  web  enabled  portal  that 
is  designed  to  facilitate  the  screening  and  subsequent  assignment  of  senior  officers  into 
positions  of  leadership  and  management.  The  second  system  is  titled  Career  Management 
System  Interactive  Detailing  System  (CMS).  It  was  designed  to  assist  enlisted  reservists 
in  managing  their  careers  by  allowing  them  to  directly  communicate  with  Assignment 
Coordinators  as  well  as  providing  the  resources  to  search  for  available  billets.  The  third  is 
titled  JOAPPLY.  JOAPPLY  is  a  component  of  the  APPLY  which  is  designed  to  help 
Naval  Reserve  leadership  place  junior  officers  in  appropriate  billets.  JOAPPLY  also 
provides  junior  officer’s  with  a  resource  in  which  they  can  explore  career  opportunities 
drawn  from  the  entire  billet  base  of  the  Naval  Reserve  that  is  available  assignment  [14]. 
JOAPPLY  aligns  closest  with  what  the  Marine  Corps  wants  to  do  with  their  system  so 
our  primary  analysis  will  focus  on  it. 

1.  JOAPPLY  Background 

After  the  success  of  the  Apply  system  for  billeting  senior  leadership  in  the  Naval 
Reserve  it  was  determined  that  a  system  needed  to  be  built  for  the  junior  officers  that 
provided  them  with  similar  resources.  JOAPPLY  was  modeled  after  the  CMS  system  in 
the  sense  that  it  was  designed  to  be  an  interactive  and  dynamic  application  that  allowed 
junior  officers  to  actively  manage  their  career  [15].  The  previous  system,  JASS,  only 
allowed  sailors  to  view  jobs,  and  did  not  provide  sailors  with  an  avenue  in  which  they 
could  apply  for  billets  they  were  interested  in  without  the  help  of  a  command 
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representative.  This  process  did  not  provide  sailors  with  the  ability  to  manage  their 
career  nor  did  it  really  give  employers  any  sense  on  whether  the  applicants  applying  for 
vacant  billets  were  qualified. 

2.  JOAPPLY  Process  Overview 

JOAPPLY  is  a  four-phase,  time  driven  process.  The  first  phase,  depicted  in  blue 
in  Figure  10,  allows  Operational  Support  Officers  (OSO),  program  managers,  the  ability 
to  create,  read,  update  and  delete  advertised  billets.  It  also  provides  the  OSOs  with  the 
ability  to  insert  comments  and  provide  applicable  infonnation  about  the  billets  being 
advertised.  The  second  phase,  depicted  in  green  in  Figure  10,  allows  Reserve  Component 
Junior  Officer’s  (RCJOs),  which  are  defined  as  junior  officers  assigned  to  the  active 
Naval  Reserve,  to  apply  for  vacant  billets  in  the  Naval  Reserve  as  long  as  they  are  within 
prescribed  detailing  windows.  The  third  phase,  depicted  in  yellow  in  Figure  10,  gives  the 
OSO  and  Commanding  Officers  (CO)  the  ability  to  review,  prioritize  and  comment  on 
each  application  made  for  vacant  billets.  Ranking  and  comments  can  only  be  done  during 
this  window.  The  fourth  phase,  depicted  in  red  (Figure  10),  is  where  CNRFC  N12 
Assignment  Coordinators  review  all  applicants,  the  OSOs  and  COs  rankings  and 
comments,  then  slate  the  Junior  Officers  to  billets  [16]. 
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Application  Schedule 
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JOAPPLY  AVAILABLE  FOR  COMMAND  COMMENTS  ON  BILLETS  (No  Applications  allowed.  Command  Comments  onM 
■  JOAPPLY  AVAILABLE  FOR  APPLICATIONS 

J  i  JOAPPLY  AVAILABLE  FOR  COMMAND  COMMENTS  ON  APPLICANTS  (No  Applications  allowed.  Command  Commends  only) 
HI  ASSIGNMENT  COORDINATORS  MAKE  ASSIGNMENTS 


Figure  10.  JOAPPLY  Application  Schedule 


3.  JOAPPLY  Stakeholders  and  Functional  Overview 

There  are  four  types  of  primary  users  that  were  identified  by  JOAPPLY 
requirements  document:  Reserve  Component  Reserve  Component  Junior  Officers 
(RCJO),  Reserve  Component  Detailers  (RCD),  Reserve  Component  Program  Managers 
(RCPM)  and  Reserve  Junior  Officer  Interactive  Detailing  Managers  (RJOID).  Each  of 
these  different  roles  is  afforded  different  levels  of  access  to  the  functionalities  of  the 
system.  Access  is  based  on  the  position  that  the  JOAPPLY  user  is  filling. 
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RCJOs  are  the  primary  business  users  of  the  system.  That  being  said,  they  have  a 
dynamic  and  rich  user  interface  that  allows  them  actively  manage  their  career,  as  well  as, 
search  and  apply  for  future  positions.  Within  the  context  of  this  thesis,  RCJOs  correlate  to 
a  Marine  Reserve  in  the  legacy  RDOL  system,  but  the  Navy’s  definition  of  reservist  is  a 
more  stringent  in  the  sense  that  the  Navy  only  grants  active  reservists  access  to  the 
system. 


®  JHpp  W 

|  You 

roww  Vjc  jr  l  JO  BlIKH  You  mull 

anno*  "apply"  In  tfil*  mo<J*  :\  ~ 

login  to  apply 

■■■■ 

Figure  1 1 .  Login  Process  for  JOAPPLY 

When  a  RCJO  attempts  to  enter  the  system  he  or  she  must  go  through  the  Apply 
system  as  depicted  on  the  left  screen  shot  of  Figure  11.  Once  the  user  clicks  on  the 
JOAPPLY  link,  the  user  is  routed  to  the  login  page  and  the  RCJO  then  logins  in  via  CAC 
authentication  or  via  password  authentication.  This  is  similar  to  the  RDOL  process  which 
utilizes  Marine  Online  (MOL)  LDAP  services  or  password  access  to  authenticate  its 
users.  After  logging  in,  RCJOs  will  be  directed  to  their  homepage  which  is  depicted  in 
Figure  12.  The  homepage  contains  two  functional  sections:  The  Profile  and  Registration 
section  and  the  Assignment  Tools  section. 
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Reserve  Officer  Menu 

LCDR  Brar.c-  Head.  Welcome  lo  the  APPLY  website'  All  Reserve  Oftcets  are  required  to  maintain  an  up-to-date  profile 
in  the  AFPLY  sy  stem,  regardless  ot  their  des-re  to  apply  for  a  bil'et  You*  registration/profi'e  is  considered  up-to-date  rf 
all  sections  h  ivo  been  reviewed  during  the  current  calendar  year 

Profile  and  Registration 

...T.  1  Y At  .  .U..I.IIMI  ...  r.,,-/,|#  p  .A 

Profile  & 
Registration 
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**  Cuuent  Assiqnmert  iTt  •••  •  in  t  70  ’ 

*'  B-llet  History  L.-.t  Reviewed  On  (■  .'If. 'A X' 

**  Personal  Data  and  Contact  Information  Litl  Renewed  on  t/3t/2007 
**  Qua'*-:  ,«t  on >  -  *  •  *  i  • 

FY08  APPLY  Board  Results 

[  The  F  Y08  APPLY  Board  has  ended  Click  here  to  view  Jh*  board  results  as  an  Adobe  PDF  file 

Junior  Officer  APPLY 

Assignment 

Tools 

- - 

The  tools  in  this  section  will  allow  you  to  search  vacant  non-comrnand  Junior  Officer  opportunity .  jw-irded  though  the 
APPLY  system  and  a!  crw  you  to  apf  y  for  those  ass  jnments  Seme*  Officers.  olicers  with  more  than  1  year  of  tenure 
remaining  m  an  assignment,  and  officer  who  have  not  completed  registration  ws'i  t>e  unable  to  use  these  tools 

-  v£  iCjo  lm^sch.*ti» 

Unit  CO  Tools 

Please  follow  the  link  be'ow  to  review  the  officer  b->!ets  in  your  unrt 

Figure  12.  Member’s  Homepage 


The  first  functional  section,  the  Profile  and  Registration  section,  contains  a 
Current  Assignment  subsection,  a  Billet  History  subsection,  a  Personal  Data  and  Contact 
Information  subsection  and  a  Qualifications  subsections.  When  RCJO  signs  onto  the 
system  for  the  first  time  they  are  prevented  from  accessing  other  functionality  of  the 
system  until  they  verify  their  personnel  data,  this  is  depicted  in  Figure  13.  RDOL  does 
not  currently  make  a  Marine  verify  their  personal  information  before  using  the  system, 
which  causes  complications  in  the  selection  process. 


Your  registration  is  not  complete  Please  update  your  profile  to  complete  registration  with  the  APPLY  website  Please 
address  the  areas  marked  in  red 

**  Current  Assignment  Last  Reviewed  on  1/1/2006 
”  Billet  History  Last  Reviewed  on  6/15/2007 

"  Personal  Data  and  Contact  Information  Last  Reviewed  on  1/31/2007 
**  Qualifications  Last  Reviewed  on  1/31/2007 


Figure  13.  PR  Initial  login  prompt  to  update 
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Within  the  current  assignment  subsection  (Figure  14)  the  user  must  verify  that  all 
of  their  current  billet  information  contained  within  the  system  is  correct.  The  information 
displayed  comes  directly  from  the  Reserve  Headquarters  System;  therefore  any 
inaccuracies  must  be  corrected  through  the  member’s  parent  reserve  activity. 


S 


Registration:  CurrentAssignment  Information 


Data  as  it  reflects 
in  RHS  and  NSIPS 


What  to  do  if 
the  data  is 
inaccurate 


Do  you  agree 
with  the  data? 


A»«lanm«nt  Information 


Current  records  (NSIPS/RH 

BIN: 

Assignment  Title: 

Desiq  Rank.  C orntmind: 
Assigned  Unit: 

RBSC: 

AINO 

PRO:  ? 

Billet  Deletion  Date:  ? 


Data)  indicate  the  following  assignm* 

0001772 

NAV  SCI  PSCH 

IOOO/CAPT/CO 

\P  ONR/NRL  SAT  HO  100  (89160) 

0137 

CNR  ARLINGTON  VA  (00014) 
20000930 

NO  DELETION  DATE  LISTED 


V  you  have  incomplete  or  rnttsmg  data  on  this  screen  then  you  are  either  not  in  a  billet  or  your  assignment  e>  NSIPS 
and  RHS  *s  evcomplfte  K  there  is  no  information  ktted  on  this  screen  you  are  currently  not  in  an  assigned  bidet  0  you 
believe  that  you  should  be  assigned  to  a  billet  and  the  information  on  this  screen  does  not  reject  ihal  issignment  then 
you  MUST  contact  your  reserve  aclrwty  to  resolve  your  assignment  discrepancy  All  of  the  data  on  this  screen  comes 
directly  from  Reserve  Headquarters  System  (RHS)  wtech  is  the  sole,  definitive  database  ter  personnel  asvgnments  4 
the  above  information  rt  incorrect  or  blank,  contact  your  reserve  activity  to  venfy  your  current  assignment  as  directed  m 
the  COMUAVfcESFORCCAINOTE  5400 


You  Iasi  reviewed  this  information  on 
Do  you  agiee  that  the  NSIPS/RHS  « 
section  of  your  profile  by  setecteig  (j 


nthis 


reen  is  accurate' 


It  you  are  unsure  of  the  accui 
|  I  don't  know 


Yes  )  or  |  No  | 

the  presented  information,  you  may  tern 


•iy  skip  this  secton  by  clicking 


Figure  14.  Current  Assignment  Verification 


The  Billet  History  subsection  allows  the  member  to  verify  that  their  chronological 
billet  history  is  accurate.  Members  can  edit,  delete  and  add  historical  billet  entries  to  this 
section  (Figure  15). 
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Registration:  Billet  History  Data 


You  can  edit 
this 

information 


Click  here  to 
edit  the 
billet  info 


Billet  History 


The  billet  history  provides  the  board  with  information  to  belter  match  you  to  a  vacancy  This  is  critical  information  used 
by  the  board  during  the  slating  process  and  can  weigh  heavily  during  billel  assignment  Make  sure  your  billet  history  is 
accurate  and  complete  To  confirm  that  you  have  reviewed  this  information,  scroll  to  the  bottom  of  the  page  and  press 
the  'Review  Confirmation’  button 

Click  on  a  Edit  to  change  the  information  for  that  entry  Click  on  Delete  to  permanently  remove  the  entry  from  your 
application 

Click  billets  to  your  history 


From  To  Billet  Unit  CO 

Billet 

Paygrade 

Interim  Active/ 
Fill  Reserve 

" — 

Edit  Delete  200201  pres  test  test 

CO 

CAPT 

Y 

R 

Edit  Delete  200001  200112lest  test 

QIC  [COR 

N _ 

A 

You  last  reviewed  this  infoimation  on 
please  press  the  button  |  Review  Confirmation 


To  acknowledge  that  you  have  reviewed  the  contents  of  this  page, 


Figure  15.  Billet  History  Data 

The  Personal  Data  section  (Figure  16)  allows  the  member  to  verify  their  SSN, 
Name,  Date  of  Birth,  Designator,  Rank,  Promotion,  Date  of  Rank,  Address,  Home  Phone 
and  Work  Phone.  All  the  data  displayed  in  this  subsection  is  from  the  RHS  repository,  so 
if  anything  is  inaccurate  in  this  section  the  member  needs  to  contact  his  or  her  reserve 
activity  to  update  the  information. 
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Personal  Data  and  Contact  Information 


To  confirm  that  you  have  reviewed  the  information  in  this  section  of  your  profile,  scroll  to  the  bottom  of  the  page  and 
press  the  ’Review  Confirmation'  button 


Dfita  from  your  Reseive  Personnel  File  (NSIPS  RHS):  If  any  of  this  data  is  incorrect  contact  your  Reserve  Activity 
(Reserve  Center.  MAR  or  NOSC)  to  update  your  record  in  NSIPS 


SSN 

Name 

Brandi  Head 

This  data  is  from 

Dale  of  Birth 

NSIPS  &  RHS. 

Designator 

Rank 

Promotion 

Date  of  Rank 

1125 

ICOR 

Not  Currently  Selected  for  Paygrade  Promotion 

You  must  contact 
your  NOSC  if  this 
information  is 

Address 

Incorrect. 

Home  Phone 

Work  Phone 

Figure  16.  Personal  Data  and  Contact  Information 

The  Qualifications  subsection  (Figure  17)  gives  the  member  the  ability  to  review 
their  clearance,  their  NOBC(s),  AQD(s),  Subspecialties  and  any  Education  entries.  The 
goal  of  this  section  is  to  ensure  that  a  RCJOs  resume  is  accurate  before  it  goes  before  a 
selection  board.  If  RCJO  discovers  and  error  there  is  a  matrix  was  made  for  a  reservist  to 
address  the  mistakes. 
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Registration:  Qualifications 


If  any  of  the  info 
on  this  screen  is 
incorrect,  see  the 
“Discrepancy 
Matrix”  for 
assistance. 


*  any  of  Ihe  information  on  this  screen  i*  incorrect.  tee  lhe  for  aisr.tance  in  determrmg  the 

c o»ec!  pont  of  coot»ct  for  confection*  To  confirm  that  you  have  renewed  the  rformetion  in  thr*  section  of  you>  pro&> 
1C  rod  to  the  bottom  of  the  page  end  prett  Ihe  "Review  Confirmation’  button 

Cleat  .nice:  There  it  no  tecunty  clearance  tilted 

N08Cc:  There  ere  no  N08C  enlnet 

AODv  There  ere  no  AOD  entries 

Siibvpcci.ihirv  "here  ere  no  Sub'.p*i  *lty  entriei 

Education:  There  t re  no  Education  entries 

You  test  renewed  thee  information  on  t  J  ’  To  acknowledge  that  you  have  renewed  the  content*  of  this  page, 
please  prett  the  button  FLevvew ConkrmoOonj 


Figure  17.  Qualification  Summary 


The  second  functional  section,  the  Assignment  Tools  section,  allows  the  reservist 
to  actively  search  and  apply  for  vacant  billets,  but,  as  depicted  in  Figure  18,  a  RCJO 
cannot  view  or  apply  for  vacant  billets  unless  they  are  within  12  months  of  their  PRD  and 
their  personal  information  in  the  Profile  and  Registration  section  has  to  have  been 
reviewed  by  the  member. 
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1  You  must  be  within  12  months  of  your  PRD  in  order  to  Apply  for  a  billet.  | 
If  you  are  outside  the  12  month  window,  you  will  receive  this  notice. 


Junior  Officer  APPLY 


You  have  more  than  1  yeat  of  tenute  left  in  your  current  assignment  You  may  not  review/apply  for  a  new  assignment  at 
this  time 

**  (note  the  Browse  tool  does  not  allow  applications  ) 


Figure  18.  PRD  Alert 


Once  a  member  is  within  their  12  month  PRD  window,  the  RCJO  can  search  and 
apply  for  vacant  billets,  view  their  dreamsheet  and  view  the  JOAPPLY  schedule. 

When  a  RCJO  navigates  to  search  for  a  vacant  billet  by  clicking  on  the  “Search 
for  Junior  Officer  Assignments”  link  (Figure  19)  they  are  able  to  enter  the  following 
arguments  for  their  search  query:  Rank,  Designator,  NOBC,  RUIC,  NRA,  RCC  and 
Program  Code.  The  system  uses  the  Reserve  Functional  Area  and  Sex  (RFAS)  codes  to 
match  search  criteria  with  available  billets.  In  addition  to  searching  by  the 
aforementioned  criteria,  reservists  are  able  to  rank  their  preferences  based  on  assignment 
location  as  well  as  by  specific  professional  attributes  [17]. 
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Filter  Capabilities: 
Rank 

Designator 

NOBC 

RUIC 
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RCC 

Program  Code 
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i 


Figure  19.  Search  Screen  Page 


The  search  results  page  (Figure  20)  will  display  the  Billet  Title,  Unit  Name, 
RUIC,  RBSC  and  Designator  of  all  the  results  returned  by  the  query.  The  member  can 
then  choose  to  view  the  details  of  a  billet,  navigate  to  additional  results  (if  applicable)  or 
add  the  job  to  their  dreamsheet.  A  member  can  select  up  to  three  billets  to  add  to  their 
dreamsheet  [17]. 
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Search  Result: 

Shown  below  are  all  the  billets  matching  your  search  criteria  Click  on  Details  to  view  the  billet  details 
to  add  the  billet  to  you*  Oreamsheet  Click  on  the  column  heading  to  sort  by  that  field 
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Details  Add 
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: '  r  1--; 
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Details  Add 
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1110 

DetailsUdd 

DES  <  OFFICER 

NRSEALOGEUR 
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89271 

7034 

1110 

Details  Add 

PUB:  .1C  AFFAIRS  OFF  15/49 

NR  USPACOM  PET 
!  120 

89631 

7119 

1000 

ll1234§6Z281fi_  II 

Figure  20.  Search  Results  Page 

As  depicted  in  Figure  21,  when  a  member  navigates  to  a  specific  billet’s  detail 
page,  the  unit  information,  the  billet  information  and  command  information  will  be 
displayed.  The  unit  information  includes  the  Name,  Short  Title,  RUIC,  AUIC,  the  reserve 
activity  name  and  the  Commanding  Officer’s  name.  The  billet  information  contains  the 
billet  identification  number  (BIN),  the  PRD,  the  number  of  applicants,  description  of  the 
billet,  rank  requirement,  command  type,  RSBC,  VRFAS,  HRFAS,NOBC  requirements, 
drill  location,  drill  frequency,  weekend  drill  and  security  clearance  requirements.  The 
command  information  results  section  will  include  the  supported  command  name,  mission 
type,  location,  any  comments  about  the  billet  from  the  supported  command  and 
comments  from  the  commanding  officer  of  the  command  [17].  This  breadth  of  this 
information  gives  the  reservist  an  extremely  accurate  representation  of  a  specific  vacant 
billet  which  ensures  that  it  truly  is  a  job  that  the  RCJO  is  interested  in. 
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Billet  Details 


Unit  Information 


Supported  Command 
Information 


Unit  Information 


Billet  Information 


CD*?  KRISTI  SCEBO 


VPf  AS  l  CORTKffULT 

■ 

NOBC  Poqu>r*m««s  PK1  90^ 

Additional  Billet  Information 


Supported  Command  Information 


Figure  2 1 .  Search  Details  Page 

If  a  member  desires  to  apply  for  a  billet  he  or  she  hits  the  apply  button,  and  it  is 
added  to  the  member’s  dreamsheet.  Once  the  application  is  submitted,  the  search  page 
will  update  and  the  member  will  be  able  see  the  “add  to  dreamsheet”  column  updated  to 
reflect  the  applied  for  status  as  depicted  in  Figure  22.  The  member  will  also  receive  a 
confirmation  email  that  will  be  sent  to  their  primary  email  address.  Again,  a  member  is 
only  able  to  apply  for  three  billets  at  one  time,  but  if  the  member  attempts  to  add  more 
than  three  billets  to  his  or  her  dreamsheet  then  the  system  will  provide  the  user  the  ability 
to  remove  a  billet  on  their  dreamsheet  in  order  to  accommodate  the  new  application. 
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Add  to 
Dreamsheet 

Billet  Title 

Unit  Name 

RUIC 

RBSC 

Desiq 

Details 

On 

Dreamsheet 

OP  CTLCEN  BRF/N423RW1 1 1 
CACB 

NR  CNO  FLEET 
READ  AND  LOG 

87987 

7028 

1000 

Figure  22.  Updated  Billet  Status  Within  Search  Results  Page 


The  dreamsheet  will  display  all  the  billets  that  are  in  the  queue  of  the  member.  As 
depicted  in  Figure  23,  the  dreamsheet  page  will  display  the  billets  name,  the  unit’s  name, 
RSBC,  designator  and  rank  of  the  billet.  It  will  also  provide  the  member  with  the  ability 


Tm  AffkuMN  C 


Removing  and  adding  billets  and  modifying  application  comments  is  only 
allowed  during  the  application  phase  of  the  JOAPPLY  cycle. 


Figure  23.  Dreamsheet  page 


to  remove  a  billet  from  their  queue  as  well  as  include  comments  for  the  detailer  and 

command  representatives  to  review.  A  member  can  only  modify  or  delete  billets  during 

the  application  phase  of  the  detail  cycle.  Once  the  application  phase  has  closed,  the  RCJO 
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must  wait  for  the  OSO  review  cycle  and  the  Assignment  Coordinator  review  cycle  to 
complete  before  learning  the  results  of  the  application  process.  Whether  selected  or  not 
the  RCJO  will  receive  an  email  infonning  them  of  the  results  of  the  application  process. 
If  the  RCJO  was  not  selected  the  process  begins  over  again,  and  if  the  candidate  was 
selected  then  orders  will  be  sent  to  the  gaining  and  losing  commands,  as  well  as,  to  the 
member. 

The  acronym  RCPM  is  synonymous  with  OSO.  An  OSO’s  homepage  (Figure  24) 
has  the  similar  look  and  feel  of  the  RCJO’s  homepage,  but  the  management  role  provides 
the  OSO  with  greater  latitude  within  the  system  due  to  requirement  of  their  managerial 
position.  Again  there  are  two  function  sections,  in  this  case  the  profile  and  registration 
section  is  not  as  dynamic  because  the  required  information  is  captured  during  the  initial 
access  process.  The  section  does  provide  the  OSO  with  the  ability  to  update  contact 
information,  as  well  as,  access  CNRF  N12’s  administrative  tools. 
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Figure  24.  OSO  Homepage 

The  OSO  Assignment  Tools  functional  section  is  much  more  significant,  and  will 
be  discussed  in  greater  detail.  When  the  OSO  follows  the  “Search  Jo  APPLY  Billet”  link 
the  OSO  search  page  will  be  called.  As  depicted  from  Figure  25,  from  the  search  page  an 
OSO  can  search  for  an  individual  billet  by  the  Billet  Identification  Number  (BIN),  or  the 
OSO  can  search  for  a  group  of  billets  based  on  their  RUIC  or  the  OSO  can  search  for  an 
individual  billet  by  using  the  descriptive  search  criteria  to  discover  the  billet  of  interest. 
The  OSO  is  also  able  to  filter  by  whether  the  job  was  advertised  or  not  and  whether  the 
vacancy  has  applicants  or  not. 
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Figure  25.  OSO  Search  Page 

Once  the  submit  button  is  entered  a  search  results  page  is  generated  which  will 
provide  the  OSO  with  the  results  of  his  or  her  query,  as  well  as,  provide  further 
navigation.  Figure  26  depicts  the  results  page  and  the  fields  that  are  editable.  The  OSO  is 
able  to  edit  both  the  Additional  Billet  Information  and  the  Supported  Command 
Information,  but  is  unable  to  update  the  core  billet  information  that  is  extracted  from  the 
RHS  database.  Within  the  Billet  Information  section,  the  number  of  applicants  currently 
in  the  queue  for  that  particular  billet  identified  by  the  query  will  also  be  displayed.  The 
detail  page  also  shows  the  OSO  if  a  billet  will  be  displayed  in  the  next  advertisement 
cycle. 
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Figure  26.  Single  Billet  Results  Page 


From  the  billet  results  page  the  OSO  is  also  able  view  the  pool  of  candidates  that 
have  applied  for  the  vacant  billet.  As  Figure  27  depicts,  the  OSO  is  then  able  to  rank  and 
post  comments  on  each  candidate,  which  will  be  reviewed  by  the  Assignment 
Coordinators  during  the  selection  process. 


39 


IfXPPLV 


After  reviewing 
applicant 
details 
OSO's  have 
the  ability 
to  rank  the 
applicants 
or  disapprove 
them . 


Af  j  c  vis ‘or  Billet  89161/70ia«)04SS9 

Clicking  "View  details’  wt  di  5p:sy  add/K^s 
lot  e*:h  applicant  Selecting  ‘Disapprove*  writ 
on  an  app'icant  c lick  the  tnk  for  ‘Comment -/ 

l  apptcants  found  for  th-s  Wtet 


Applicant  Grid 


■‘c'mat'O'i  on  the  app':cant  Chck  the  d»op  down  bo*  to  select  a  priority 
remove  the  *;;  ■  ji*  from  consider  *t  or  ‘or  thtt  b>ilet  To  make  rema*. 


Priority  Name 


JAMES  BEER 
S$  JAMES  CULLEN 
I  ROBERT  FIRNSTEIN 
ETH  PARSONS 


View  Details  about 
the  applicant 
(see  next  slide) 


Designator 


1115 

1315 


Insert  comments 
concerning  the 
applicant. 


18 


Figure  27.  OSO  Candidate  Pool 


The  Reserve  Component  Detailers  have  very  little  functionality  within  the  system. 
They  are  able  to  perform  a  generic  search  form  the  APPLY  homepage.  This  search  will 
provide  them  with  a  details  page  off  all  the  empty  or  soon  to  be  empty  billets  in  the  Naval 
Reserve.  If  they  find  a  billet  that  a  perspective  candidate  can  fill,  they  are  instructed  to 
call  a  point  of  contact  at  NRFS  N12.  This  POC  will  then  be  able  to  gain  the  new  member 
which  then  allows  the  member  to  access  the  system.  This  limited  functionality  severely 
limits  the  usability  of  the  system  for  detailers. 

4.  JOAPPLY  Conclusions 

JO  APPLY  has  many  attributes  that  are  desirable  for  the  next  Marine  Corps 

Reserve  Billet  Advertising  System.  Billets  are  tied  to  Billet  Identification  Number;  the 

system  uses  this  attribute  to  automatically  advertise  in  the  system  when  they  are  within 

12  months  of  them  being  vacated.  Members  are  able  to  see,  and  are  forced  to  update,  all 
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of  their  personal  and  professional  information,  which  keeps  the  members  actively 
engaged  in  managing  their  careers.  Members  are  also  able  to  dynamically  search  and 
apply  for  jobs  that  interest  them;  this  induces  and  promotes  harmony  during  the  process. 
On  the  management  side,  OSOs  and  COs  are  able  to  rank  and  provide  feedback  on 
potential  candidates.  This  helps  commands  get  the  right  sailor  for  the  job  being 
advertised,  which  ultimately  will  improve  the  readiness  of  the  unit. 

The  system  also  has  many  undesirable  attributes.  First  the  system  has  little  to  no 
documentation.  And  what  little  documentation  that  does  exist  doesn’t  correlate  to  the 
system  that  is  being  currently  utilized.  Second,  the  system  provides  very  limited 
functionality  for  the  detailers,  which  makes  the  system  basically  useless  to  them.  Which 
leads  us  directly  to  the  third  point;  access  is  limited  to  members  of  the  active  Naval 
Reserve  and  it  provides  little  access  to  a  potential  recruit.  Specifically  if  somebody  is 
interested  in  joining  the  Naval  Reserve  they  cannot  access  the  system  to  browse  the 
available  billets.  They  have  to  go  to  a  recruiter,  who  also  doesn’t  have  access  to  this 
system,  so  it  is  almost  impossible  for  some  to  easily  identify  potential  billets  of  interest. 
Finally,  the  system  was  designed  to  curtail  the  good  old  boy  system  by  preventing 
preferential  treatment  of  candidates  by  providing  an  unbiased  application  process. 
Unfortunately  the  current  design  of  the  process  makes  it  easy  for  candidates  to  be 
discriminated  against  due  to  familiarity  of  the  OSO  with  other  candidates.  There  is  no 
checks  and  balance  system  to  ensure  that  the  OSO  is  being  equitable  and  fair  when 
ranking  members. 

C.  MONSTER.COM  AND  USAJOBS.COM 

Monster.com,  founded  in  1994,  is  a  twelve  year  old  multinational  company  that 
specializes  in  online  recruitment  of  potential  applicants  for  vacant  positions  advertised  by 
a  plethora  of  different  employers.  In  its  current  configuration  the  corporation  has  17 
unique  job  search  networks  and  40  international  sites  which  encompass  both  commercial 
and  academic  institution  portals  [18].  This  congregation  of  resources  has  created  an 
impressive  data  warehouse  of  potential  candidates.  In  fact,  as  of  June  2007,  Monster  and 
its  subsidiaries  housed  over  80  million  unique  job  seeker  resumes  and  50,000  more  are 
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added  each  day  [19].  The  corporation  has  also  worked  diligently  at  maximizing  its  brand 
recognition  through  a  complex  web  of  partnerships  and  community  sites. 

According  to  a  Taylor  Nelson  Sofres  (TNS)  survey  performed  in  the  fourth 
quarter  of  2006,  their  efforts  have  proved  fruitful  as  9  out  of  10  respondents  to  a  market 
survey  recognized  Monster.com  and  its  mission  [19]. 

The  remainder  of  this  section  will  focus  on  one  of  Monster  subsidiaries: 
USAJOBs.com.  USAJOBS.com  is  a  good  example  of  a  potential  solution  that 
Monster.com  can  provide  the  Marine  Corps  in  its  endeavor  to  produce  the  next  iteration 
of  RDOL.  USAJOBs.com  was  built  as  part  of  the  E-Govemment  initiative  introduced  by 
the  Bush  administration.  Its  goals  were  to  provide  “state-of-the-art  on-line  recruitment 
services”,  serve  as  a  single  sign  on  application  point,  to  provide  a  competitive  advantage 
for  government  agencies  trying  to  hire  top  talent  and  to  improve  the  effectiveness  of  the 
federal  government’s  job  recruiters  [20].  These  provide  the  Marine  Corps  with  a  Product 
Line  Architecture  in  which  it  can  achieve  its  overarching  goals  of  Marine  Corps  for  its 
next  system,  so  it  makes  it  a  natural  choice  to  compare  and  contrast. 

1,  Technologies  Leveraged  by  USAJOBs.com 

At  the  core  of  USAJOBs.com  is  an  application  titled  Recruitment  One-Stop 
(ROS).  This  application  processes  the  requests  and  information  submitted  by  the  different 
federal  government  agencies  by  calling  the  appropriate  Monster.com  resource.  Specific 
Monster.com  resources  deployed  in  this  project  include  proprietary  technologies  such  as 
Monster  Career  Center,  Monster  Officer  HQ  and  its  job  search  engines  [20].  These 
resources  are  melded  together  with  functionality  created  exclusively  for  the  project  in 
order  to  meet  the  needs  of  the  federal  govermnent.  The  use  of  existing  technologies  with 
new  technologies  has  created  a  dynamic  and  professional  that  has  seamless  integrated 
commercial  products  with  governmental  agencies  legacy  systems. 

ROS  is  connected  to  the  government  agencies  through  a  proprietary  middleware 
application  titled  Monster  Business  Gateway  (BGW).  As  exhibited  in  Figure  28,  BGW  is 
the  only  interface  between  the  ROS  and  the  government  sites.  It  uses  basic  message 
protocols  and  standards  to  facilitate  communication  between  the  different  systems. 
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Specifically  it  uses  SOAP  XML  requests  over  HTTP/HTTPS  and  FTP/FTPS  to 
communicate  between  the  BGW  and  the  Agency  applications  [20].  The  protocol  utilize 
depends  on  the  data  size  and  the  data  latency  requirements  of  the  function  using  the 
service.  The  data  itself  is  stored  in  a  database  schema  of  the  users  choice.  According  to 
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Figure  28.  Depiction  ofMonster.com  Business  Gateway 

Dave  Concordia,  Monster’s  Director  of  Development  for  Government  Solutions, 
reiterated  that  Monster  can  support  any  type  of  database  from  relational  databases  to 
object  oriented  databases  and  anything  in  between  [21].  Monster  periodically  updates  its 
database  schemas  to  reflect  the  new  needs  of  its  customers  as  well  as  to  keep  pace  with 
technological  advances.  But  most  of  these  upgrades  are  backward  compatible  with 
current  systems  which  make  them  transparent  to  the  user. 

As  shown  in  Figure  29,  the  Government  Agencies  are  required  to  use  the  World 
Wide  Web  to  transfer  information  to  and  from  USAJOBs.com.  Using  the  web  as  the 
medium  makes  data  security  and  integrity  paramount.  Monster  employs  a  two  pronged 
approach  in  its  attempt  to  meet  these  security  needs.  First  the  data  is  transmitted  between 
the  BGW  and  the  Agency  systems  via  HTTPS  or  FTPS  protocols.  The  second  security 
measure  implemented  by  Monster  is  the  incorporation  of  an  encrypted  Customer  Access 
Ticket  (CAT)  into  the  header  of  the  SOAP  message.  The  CAT  uniquely  identifies, 
verifies  and  authenticates  a  user.  Monster  distributes  and  manages  a  master  CAT  list,  but 
the  content  of  the  header  is  managed  by  outside  agency.  Once  a  user  has  been 
authenticated,  Monster  verifies  that  the  individual  user  has  the  proper  licenses  and 
pennissions  to  complete  the  transaction  requested  [20], 
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2.  USAJOBs  Employer  Functional  Processes 

Employers  are  provided  a  CAT,  access  and  authority  to  manipulate 
advertisements  from  the  agencies  in  which  they  are  employed.  Monster  uses  these 
credentials  to  ensure  that  they  employer  has  the  rights  to  perfonn  add,  delete  or  modify  to 
advertisements  within  ROS.  Employers  have  the  ability  to  add  single  or  batch 
advertisements.  Once  the  advertisements  are  posted,  Employers  have  a  robust  set  of  tools 
to  monitor  activity  and  managing  their  applications. 

For  example,  Employers  are  notified  when  an  application  is  submitted  for  one  of 
their  advertisements.  Figure  29  depicts  the  flow  of  the  application  from  the  ROS  to  the 
Agency  itself.  This  process  provides  positive  feedback  for  both  the  employer  and  the 
applicant  that  an  application  was  received  and  has  been  processed.  In  addition  to  the 
email,  the  employer  can  also  create  a  custom  message  that  is  displayed  to  applicant  after 
an  application  is  received.  One  of  the  disadvantages  to  this  system  is  that  responsibility 
for  catching  duplicate  application  submissions  is  delegated  to  the  agencies;  ROS  has  no 
means  to  detennine  if  the  application  is  a  duplicate. 
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Figure  29.  Application  Process  Path 


3.  USAJOBs  Applicant  Functional  Processes 

Once  an  applicant  has  found  a  job  of  interest  he  or  she  may  submit  a  resume  to 
apply  for  the  vacancy.  As  exhibited  in  Figure  30,  USAJOBs  resume  builder  is  a  four  page 
process  which  covers  four  areas:  personal  information,  the  second  area  captures  a 
member’s  experience  and  education,  the  third  area  allows  the  applicant  to  enter 
references  and  any  other  information  that  may  be  pertinent  and  the  forth  area  allows  the 
applicant  to  review,  set  interview  availability  schedules  and  error  check  the  resume 
before  posting  [22],  The  applicant  has  the  choice  on  whether  to  allow  his  or  her  private 
data  to  be  publically  available  for  employers  to  search.  Applicants  can  also  delete  or 
modify  a  resume  at  any  time.  This  resume  process  was  condensed  to  capture  what  was 
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relevant  to  federal  job  recruiters.  This  is  a  significant  point  because  it  amplifies  that  that 
the  resume  can  be  designed  to  focus  on  the  attributes  the  Marine  Corps  is  genuinely 
interested  in. 


Figure  30.  Resume  Builder  Page 


Once  the  applicant  registers  and  builds  his  or  her  resume  they  can  begin  using  the 
functionalities  of  the  site  or  start  searching  for  a  job.  A  member  can  search  for  a  job 
manually  or  virtually.  Virtual  searches  are  done  by  creating  a  “search  agent”  who 
continuously  runs  a  query  of  your  design  against  USAJOBs  job  repository.  An  applicant 
can  create  up  to  five  search  agents  to  run  simultaneously.  As  depicted  in  Figure  31,  the 
applicant  can  choose  provide  the  following  search  criteria:  by  location,  by  job  category, 
occupational  series,  by  agency,  by  salary  range,  by  job  experience  or  desire,  by  position 
title  or  by  keyword.  If  a  positive  search  result  is  returned  the  site  emails  you  the  positive 
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match  within  a  prescribed  amount  of  time  that  the  user  sets.  By  having  five  unique  search 
agents  an  applicant  can  cover  a  wide  spectrum  of  job  interests  [23].  Once  the  search  agent 


Figure  3 1 .  Job  Search  Agent  Selection  Page 


is  created  the  user  can  actively  manage  them  from  a  customized  Current  Job  Search 
homepage.  This  homepage  will  allow  you  to  view,  modify,  delete  or  add  additional  Job 
Search  Agents.  These  attributes  and  functionalities  match  significant  core  requirements 
for  the  Marine  Corps  proposed  system. 

The  applicant  can  also  search  for  jobs  manually.  The  member  has  the  ability  to 
search  by  keyword,  by  agency,  by  Federal  Series  code,  by  job  detail  (location,  salary, 
combination  etc.),  or  by  senior  executive  search.  The  results  of  the  query  are  presented  by 
either  the  age  of  the  advertisement,  newest  to  oldest,  or  by  the  keyword  relevance  [24]. 
As  shown  in  Figure  32,  the  query  results  give  the  title  of  the  position,  the  agency  that  is 
hiring  the  position,  and  where  the  vacancy  is  located  geographically.  A  member  can  click 
on  the  job  title  for  a  detail  description  of  the  requirements  of  the  vacant  position.  At  the 
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bottom  of  the  detail  description  of  the  job  posting  is  the  information  on  how  to  apply  for 
the  position.  Due  to  system  limitations,  whether  the  agencies  or  Monsters,  you  can  not 


Figure  32.  Manual  Job  Search  Results 


apply  for  every  position  online  through  USAJOBs.com  [25].  If  the  applicant  is  unable  to 
apply  through  USAJOBs.com,  the  applicant  will  either  have  to  mail  via  US  post  or  follow 
an  external  link  to  the  agencies  site  to  finish  the  application.  A  member  also  has  the 
ability  to  email  the  job  listing  to  a  friend  or  print  a  hard  copy  if  they  so  desire.  Once  the 
member  has  applied  for  the  position,  he  or  she  has  the  ability  to  track  the  application  as 
well  as  view  their  application  history  for  the  past  18  months  [25]. 

4.  USAJOBS  Conclusions 

Monster.com  solutions  provide  users  and  organizations  with  many  built  in 
advantages  that  match  the  Marine  Corps  desired  quality  attributes.  First,  the  core 
technologies  of  their  product  remain  the  same,  which  provides  the  system  with  innate 
ability  to  reuse  many  of  the  technologies.  Second,  being  a  turnkey  solution,  the  product 
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can  be  up  and  running  in  a  much  shorter  period  than  building  a  product  from  scratch. 
USAJOBs.com  took  less  than  six  months  to  deploy  the  first  iteration  of  the  product. 
Three,  the  life  cycle  a  cost  of  the  product  are  lower  than  those  of  a  proprietary  system  as 
Monster  updates  and  maintains  the  core  part  of  the  system  as  part  of  the  contract.  Four, 
the  product  will  be  exposed  to  much  broader  market  of  the  consumer  base  that  the  Marine 
Corps  is  trying  to  reach  as  the  product  will  be  crossed  advertised  in  other  Monster 
products  and  communities. 

Monster  does  have  a  few  disadvantages.  The  initial  cost,  up  front  will  be  higher 
than  building  a  system  from  scratch.  Second,  security,  though  addressed,  is  weak  at  best 
and  seems  to  be  an  afterthought  in  the  process.  Third,  the  model  assumes  that  have  access 
to  the  web  and  that  it  will  always  be  available.  This  is  not  unreasonable,  but  redundancy 
needs  to  be  built  into  the  system  to  guarantee  the  connectivity  that  Marine  Corps  desires. 
Forth,  ROS  has  no  built  in  capabilities  to  recognize  duplicate  applications.  The  onus  for 
this  task  falls  squarely  on  the  shoulders  of  the  different  agencies  which  could  lead  to 
redundant  applications  and  dirty  data  contaminating  their  data  repositories.  And  last,  the 
Marine  Corps  has  many  legacy  systems  that  do  not  have  XML  messaging  capabilities 
which  is  the  cornerstone  to  this  model.  This  will  require  additional  middleware  that  was 
not  recognized  in  the  model  presented  for  USAJOBs.com. 
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IV.  REQUIREMENTS  ANALYSIS  FOR  NEXT  GENERATION 
MARINE  CORPS  BILLET  ADVERTISEMENT  SYSTEM 


This  chapter  will  focus  on  identifying  the  Marine  Corps  requirements  for  their 
next  reserve  billet  advertisement  system.  One  of  the  primary  reasons  the  Marines  current 
billet  solicitation  system  failed  was  due  to  the  lack  of  requirements  analysis  at  the 
inception  of  the  project.  Specifically,  the  requirements  were  defined  by  a  small  group  of 
subject  matter  experts  rather  than  conducting  a  comprehensive  requirements  analysis  with 
all  the  applicable  stakeholders.  This  led  to  a  fragmented  and  incomplete  system.  To 
ensure  that  this  doesn’t  occur  again,  we  made  a  concerted  effort  to  make  sure  that  all  of 
the  stakeholders  were  included  in  the  requirements  analysis.  This  was  done  by 
conducting  phone  interviews,  analyzing  systems  with  similar  functionality,  as  well  as, 
using  a  focus  group  facilitated  by  a  professional  system  designer.  These  efforts  yielded  a 
robust  set  of  documents  in  which  we  were  able  to  leverage  during  our  analysis. 

The  results  of  our  requirements  analysis  gave  us  a  firm  understanding  of  what  the 
stakeholders  required,  and  we  expanded  upon  these  results  by  breaking  them  down  into 
the  Data  Business  Requirements  and  the  Process  Business  Requirements  of  the  next 
reserve  billet  advertisement  system  for  the  Marine  Corps.  We  discuss  first  the  Business 
Data  Requirements  which  allowed  us  to  build  the  logical  data  model  of  the  system.  This 
logical  model  will  provide  the  blueprints  for  the  implementation  of  the  next  generation 
system.  After  we  completed  the  logical  model,  we  proceeded  on  to  identify  the  Business 
Process  Requirements.  During  the  discovery  of  the  process  requirements,  the  system’s 
Context  Data  Flow  Diagram  (CDFD),  Functional  Decomposition  Diagram  (FDD)  and  its 
associated  Use  Cases  and  Process  Models  were  produced.  The  process  models  provide 
the  building  blocks  to  construct  the  system’s  sub-system  diagrams.  The  combination  of 
these  two  requirements,  the  data  and  process  requirements,  will  give  the  Marine  Corps  a 
solid  foundation  on  which  to  build  their  next  generation  system. 
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This  chapter  is  organized  in  the  following  manner:  First  we  define  and  depict  our 
data  model,  second  we  design  the  CDFD,  third,  using  the  CDFD  as  a  guide,  we  design 
the  systems  FDD  and  its  associated  components  and  finally  we  present  the  four  sub¬ 
system  diagrams. 

A.  DATA  MODEL 

After  careful  analysis  of  all  the  information  gathered  a  root  data  model  was  constructed. 
This  is  an  important  step  because  a  data  model  identifies  the  underlying  data  structure  for 
the  next  system.  There  are  several  ways  to  model  the  data  structure,  but  we  used  the 
entity  relationship  diagram  (ERD)  method.  We  chose  the  ERD  methodology  because  it 
not  only  identifies  or  captures  the  data  entities  that  the  system  needs  to  capture,  but  it  also 
defines  the  relationships  between  those  different  sources  of  data  [2],  The  core  ERD  for 
the  Marine  Corps  Reserve  is  depicted  in  Figure  33.  As  with  any  data  model,  this  should 
not  be  considered  the  conclusive  model  for  the  project,  and  it  should  be 


Figure  33.  ERD  Data  Model 
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noted  that  data  structures  need  to  be  continually  modified  to  reflect  the  current  state  of 
the  system  that  it  supports.  To  create  this  ERD,  we  first  combed  through  all  of  our 
interviews  and  notes  from  our  requirements  analysis  which  allowed  us  to  discover  our 
main  entities,  their  attributes  and  the  relationships  between  the  different  entities.  We  then 
nonnalized  the  rough  data  structure  to  second  nonnal  form. 

The  results  of  our  analysis  yielded  four  main  sub-groups  within  the  body  of  the 
ERD:  Candidates,  employers,  managers  and  recruiters.  Candidates  are  Marine  Corps 
Reservists  that  are  actively  using  the  billet  advertisement  system  to  seek  out  employment 
opportunities.  Their  personal  data  is  automatically  populated  in  the  model  from  an 
external  Marine  Corps  Enterprise  System.  The  database  will  also  capture  data  on  the 
candidate’s  personal  section  of  his  or  her  Reserve  Qualification  Summary,  their 
application  history,  their  personal  web-portal  settings,  as  well  as,  their  current  and 
historical  subscriptions  to  employment  search  engines. 

Employers  are  any  Marine  Corps  or  external  activity  that  wants  to  advertise 
vacant  employment  opportunities  within  the  Marine  Corps  Reserve  billet  advertisement 
system.  The  database  will  capture  the  employer’s  personal  infonnation,  their  historical 
and  current  advertisements,  their  personal  web-portal  settings,  as  well  as,  their  historical 
and  current  candidate  search  subscriptions. 

Recruiters  are  any  Marine  Corps  Reserve  Recruiter  who  leverages  the  system  to 
identify  potential  candidates  and  employment  opportunities  for  prospective  recruits.  The 
database  will  capture  the  recruiter’s  personal  information,  their  assigned  recruiting 
region,  their  personal  web-portal  settings,  as  well  as,  their  current  and  historical  candidate 
search  and  employment  search  subscriptions. 

The  four  main  sub-groups  are  tied  together  via  relationships  that  were  identified 
during  the  requirements  analysis.  We  will  expand  upon  the  main  relationships  that  exist 
between  each  of  the  main  entities  identified  starting  with  the  Candidate’s  relationships. 
One  of  the  primary  reasons  a  Candidate  uses  the  system  is  to  search  for  employment, 
therefore  a  significant  relationship  exists  between  a  Candidate  and  an  Employer. 
Specifically  a  Candidate  can  submit  multiple  applications  for  an  advertisement,  and 
conversely  an  advertisement  can  have  multiple  candidates  applying  for  it;  therefore,  these 
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two  entities  have  a  many-to-many  relationship.  In  order  to  apply  for  a  vacant  billet,  a 
Candidate  must  have  a  current  resume.  A  candidate  can  have  many  resumes,  current  and 
historical,  but  a  resume  only  contains  the  information  of  one  candidate.  A  candidate  also 
can  have  only  one  MOS,  Rank  and  Reserve  Category  while  all  three  of  these  entities  can 
be  associated  with  multiple  candidates.  To  assist  the  Candidate  in  searching  for  desirable 
employment,  they  will  be  able  to  subscribe  to  search  services.  A  candidate  can  have 
multiple  subscriptions  and  a  type  of  subscription  can  be  assigned  to  many  candidates. 
Any  active  subscription  for  a  Candidate  generates  leads  of  interest.  A  Candidate  can  have 
many  leads  and  a  generated  lead  will  be  disseminated  to  any  Candidate  whose 
subscription  settings  match  the  lead’s  attributes;  therefore,  it  is  a  many-to-many 
relationship.  A  Candidate  can  also  submit  a  trouble  call,  but  a  trouble  call  can  have  only 
one  creator.  In  order  to  use  any  of  these  resources  that  Candidate  has  to  be  assigned  a 
user  role  by  a  Manager.  A  Candidate  can  be  assigned  multiple  roles,  active  and  historical, 
and  a  type  of  role  can  be  assigned  to  numerous  Candidates. 

An  Employer’s  relationships  focus  around  the  management  and  maintenance  of 
billet  advertisements.  An  Employer  can  create  numerous  advertisements,  and  each 
advertisement  can  have  multiple  applicants.  Therefore,  a  many-to-many  relationship 
exists  between  an  advertisement  created  by  an  Employer  and  the  applications  submitted 
in  response  to  the  advertisement.  Each  advertisement  also  correlates  to  only  one  vacant 
billet,  but  a  billet  over  its  life  may  have  many  advertisements.  Each  billet  is  assigned  to 
only  one  command  and  each  command  can  have  multiple  billets.  To  assist  the  Employer 
in  searching  for  candidates  to  fill  their  vacant  billets,  they  will  be  able  to  subscribe  to 
search  services.  An  Employer  can  have  multiple  subscriptions  and  a  type  of  subscription 
can  be  assigned  to  many  Employers.  Any  active  subscription  for  an  Employer  generates 
leads  of  interest.  An  Employer  can  have  many  leads  and  a  generated  lead  will  be 
disseminated  to  any  Employer  whose  subscription  settings  match  the  lead’s  attributes, 
therefore  it  is  a  many-to-many  relationship.  An  Employer  can  also  submit  a  trouble  call, 
but  a  trouble  call  can  have  only  one  creator.  In  order  to  use  any  of  these  resources  an 
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Employer  has  to  be  assigned  an  Employer  role  by  a  Manager.  An  Employer  can  be 
assigned  multiple  roles,  active  and  historical,  and  a  type  of  role  can  be  assigned  to 
numerous  employers. 

At  the  heart  of  the  Recruiter’s  relationships  is  the  active  search  for  viable 
candidates  to  fill  vacant  billets  that  exist  in  the  Marine  Corps.  To  assist  the  Recruiter  in 
these  efforts  they  will  be  able  to  subscribe  to  candidate  and  billet  search  services.  A 
Recruiter  can  have  multiple  subscriptions  and  a  type  of  subscription  can  be  assigned  to 
many  Recruiters.  Any  active  subscription  for  a  Recruiter  generates  leads  of  interest.  A 
Recruiter  can  have  many  leads  and  a  generated  lead  will  be  disseminated  to  any  Recruiter 
whose  subscription  settings  match  the  lead’s  attributes,  therefore  it  is  a  many-to-many 
relationship.  A  Recruiter  can  also  submit  a  trouble  call,  but  a  trouble  call  can  have  only 
one  creator.  In  order  to  use  any  of  these  resources,  a  Recruiter  has  to  be  assigned  the 
appropriate  role  by  a  Manager.  A  Recruiter  can  be  assigned  multiple  roles,  active  and 
historical,  and  a  type  of  role  can  be  assigned  to  numerous  Recruiters.  A  Recruiter  is  also 
assigned  to  a  geographical  area  of  responsibility,  but  a  geographical  area  can  have 
multiple  recruiters  assigned  to  it. 

The  Manager’s  relationships  are  tied  to  their  primary  responsibilities  of  role 
management  and  system  maintenance  management.  A  Manager  is  responsible  for 
assigning  roles  to  the  user  of  the  system  and  they  can  also  be  assigned  multiple  roles, 
active  and  historical,  and  conversely  a  type  of  role  can  be  assigned  to  numerous 
Managers.  Managers  are  also  a  responsible  for  managing  the  trouble  call  queue  for  the 
system.  A  manager  can  be  responsible  for  multiple  trouble  calls,  and  a  trouble  call  can 
have  many  managers  who  are  responsible  for  it  over  its  life.  Each  Manager  is  able  to 
broadcast  numerous  system  messages,  but  each  message  can  only  be  created  by  one 
Manager. 

B.  CONTEXT  DATA  FLOW  DIAGRAM 

After  defining  the  data  model,  the  next  step  in  our  prescribed  methodology  is  to 
identify  and  model  the  Business  Processes.  Process  modeling  provides  stakeholders  with 
a  firm  understanding  of  the  structure  and  flow  of  data  through  systems  construct  from  the 

view  point  of  the  system  users  and  owners  [2].  The  goal  of  these  models  is  to  remove  any 
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biases  or  preconceived  notions  that  were  created  or  formed  based  on  the  current  iteration 
of  the  system.  For  this  analysis  this  is  particularly  important,  because  the  current  system 
lacks  a  sound  foundation  and  was  poorly  built,  which  has  led  to  many  ill  conceived 
opinions  about  the  system  and  its  future.  These  models  will  also  reduce  the  risk  of 
missing  business  requirements,  because  it  will  allow  us  to  provide  stakeholders  with  a 
pictorial  representation  of  the  proposed  system  which  will  afford  them  the  opportunity  to 
review  the  proposed  system  in  detail  to  ensure  that  none  of  their  requirements  are  missed. 

The  first  component  of  the  process  model  that  we  designed  was  the  Context  Data 
Flow  Diagram  (CDFD)  which  is  depicted  in  Figure  34.  The  CDFD  provides  the 
stakeholders  with  an  overview  of  the  scope  of  the  system.  We  created  this  diagram  by 
viewing  the  proposed  system  as  a  "black  box."  From  this  perspective,  in  order  to 
determine  what  inputs  the  system,  we  asked  during  interviews  what  external  systems  and 
inputs  did  the  new  system  need  to  respond  to.  After  detennining  what  the  inputs  were,  we 
then  identified  the  outputs  and  external  data  stores  of  the  system  were  by  asking  users 
what  responses  must  be  produced  by  the  system  and  where  these  responses  are  stored.  It 
is  evident  from  this  model  that  the  underlying  structure  identified  in  the  data  model  holds 
true.  Specifically,  there  are  four  significant  external  users  of  the  system:  Candidates, 
Applicants,  Employers  and  Recruiters.  At  this  level,  the  functionality  defined  in  the  data 
model  for  the  Candidate  is  encapsulated  by  the  Candidate  and  the  Applicant  Modules  in 
the  CDFD.  The  Candidate,  in  this  case,  represents  a  potential  recruit  who  wishes  to  “see” 
or  “browse”  for  opportunities  that  exist  within  the  Marine  Corps,  and  an  Applicant 
represents  a  Marine  who  is  already  in  the  system  and  is  actively  applying  for  vacant 
positions. 

The  CDFD  also  depicts  the  system’s  ties  to  several  external  Marine  Corps  data 
repositories  and  legacy  systems,  as  well  as,  identifies  areas  of  potential  growth.  The 
Monitor  Module  was  included  in  the  CDFD  in  response  to  input  provided  during 
interviews  described  future  capabilities  that  may  be  incorporated  into  the  RBAS  system 
in  the  future.  Currently  the  Marine  Corps  Reserve  does  not  have  dedicated  monitor  for 
reservists,  but  may  so  in  the  future.  That  being  said,  our  intention  from  this  point  forward 
is  not  to  include  this  module  in  our  analysis,  but  we  decided  to  leave  it  in  the  CDFD  to 
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emphasize  the  importance  of  ensuring  that  the  Marine  Corps  building  or  purchasing  a 
system  that  has  the  capacity  to  grow  dynamically  with  the  ever  changing  needs  and 
demands  of  the  Marine  Corps  Reserve. 

A  few  examples  on  how  external  systems  and  inputs  interact  with  the  system  will 
make  the  relationships  that  exist  between  the  different  systems  more  apparent  and  easy  to 
understand.  Candidate  external  systems  will  be  able  to  will  be  able  to  dynamically  search 
the  RBAS  for  billets  that  match  the  criteria  entered  into  job  search  query,  and  RBAS 
return  the  results  off  the  query  in  turn.  An  Applicant  can  dynamically  manage  their 
application  process,  as  well  as,  use  automated  job  search  services  provided  by  RBAS. 
The  Employer  external  systems  have  the  capability  to  actively  manage  advertisements, 
and  leverage  candidate  search  tools.  The  Recruiter  external  systems  are  provided  with  a 
robust  set  of  billet  and  candidate  search  tools  that  will  expedite  the  hiring  process. 
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The  M.O.L.  module  represents  Marine  Corps  legacy  systems  that  will  provide 
security  services,  as  well  as,  data  conduits  to  the  RBAS  system.  The  Monitor  module  will 
provide  a  Marine  with  a  robust  set  of  tools  to  aggressively  manage  their  careers  in 
concert  with  a  Marine  Corps  monitor. 

C.  FUNCTIONAL  DECOMPOSITION  DIAGRAMS 

Now  that  the  overall  scope  has  been  defined  and  is  understood,  the  next  process 
model  built  was  the  Functional  Decomposition  Diagram.  This  model  expands  the  “black 
box”  that  was  depicted  in  the  CDFD  into  a  construct  composed  of  its  sub-systems  which 
describe  the  proposed  system  in  detail.  Each  sub-system  has  at  a  minimum  of  two  child 
processes  or  modules  [2].  The  “children”  of  each  sub-system  provide  the  stakeholder 
with  a  comprehensive  view  of  the  different  components  or  processes  required  of  each  the 
sub-systems.  Within  each  child  module  the  model  becomes  even  more  granular  as  each 
module  is  further  broken  down  into  specific  processes  or  functionalities  required  for  that 
specific  child  module  to  accomplish  its  designed  functionality.  Each  of  these  “process  or 
functionalities”  was  identified  during  the  requirements  analysis  and  they  are  defined  in 
detail  in  use  cases  and  event  diagrams.  A  list  of  the  use  case  glossary  can  be  found  in 
Appendix  A,  and  the  actual  use  cases  themselves  are  presented  in  Appendices  B  through 
E.  The  four  distinct  sub-systems  discussed  in  the  CDFD  section  will  now  be  expanded 
upon.  We  will  elaborate  on  the  Employer  Sub-System  first,  followed  by  the  Candidate 
Sub-System,  the  Recruiter  Sub-System  and  concluding  with  the  Management  Sub- 
System. 

1.  Employer  Functional  Decomposition  Diagram 

The  Employer  Functional  Decomposition  Diagram  (EFDD),  depicted  in  Figure 
35,  contains  four  children  modules:  Process  Advertisements,  Generate  Managerial 
Reports,  Target  Potential  Candidates  and  Manage  Web  Portal  Settings. 

The  Process  Advertisement  module  contains  eleven  specific  use  cases  which  are 

presented  in  Appendix  E.  This  module  focuses  on  the  manual  and  automated 

management  of  advertisements  within  the  system.  Within  this  module  an  employer  has 

the  ability  to  manually  create,  review,  update  and  delete  any  advertisement.  The  RBAS 
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system  will  also  automatically  post  and  delete  billets  when  they  meet  prescribed  set  of 
business  criteria.  To  ensure  that  the  billets  generated  automatically  by  the  RBAS  system 
are  viable,  the  employer  responsible  for  billet  management  will  be  provided  a  two  week 
window  from  the  inception  of  the  automatically  generated  billets  to  review  and  approve 
the  advertisements.  If  the  employer  is  negligent  in  this  responsibility  and  fails  to  approve 
or  disapprove  the  billet  within  the  two  week  window,  the  billets  will  be  posted  without 
the  employer’s  approval.  This  module  also  provides  the  employer  with  ability  to  manage 
the  applicant  pool  for  specific  advertisements.  This  includes  providing  the  ability  to 
review  the  candidate  pool,  hire  a  candidate,  reject  a  candidate,  manage  leads,  as  well  as, 
communicate  with  entire  applicant  pool. 

The  Generate  Managerial  Reports  module  will  provide  the  employer  with  ability 
to  generate  a  user  defined  report,  advertisement  history  report,  an  advertisement  details 
report,  an  advertisement  response  report  and  a  billet  expiry  report.  The  billet  expiry 
report  is  generated  automatically  and  will  be  driven  by  temporal  events  at  30,  14,  7  and  - 
14  days  of  the  expiration  date  of  the  advertisement. 

The  Target  Potential  Applicants  module  allows  the  employer  to  create,  review,  update 
and  delete  subscriptions  that  actively  search  for  potential  candidates.  These  subscriptions 
are  an  automated  service  that  provides  the  user  with  the  matching  results  of  employment 
queries  that  are  applied  continuously  against  the  RBAS  data  repository.  These  services 
are  voluntary  and  must  be  signed  up  for  by  the  candidate.  This  module  also  allows  the 
employer  to  manually  search  for  a  specific  candidate,  as  well  as,  contact  them. 

The  Manage  Web-Portal  module  allows  an  employer  to  create,  review,  update  and 
delete  an  employer’s  personal  web  portal  content.  This  allows  the  employer  to 
dynamically  change  their  environment  to  suit  their  needs  and  desires.  This  customizable 
interface  would  allow  them  to  subscribe  to  Really  Simple  Syndication  (RSS)  broadcasts 
which  include  blog  entries,  news  headlines,  and  podcasts  in  a  standardized  format.  They 
will  also  be  able  to  modify  their  background,  install  web  widgets  and  view  results  of 
RBAS  subscription  notifications. 
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2.  Candidate  Functional  Decomposition  Diagram 

The  Candidate  Functional  Decomposition  Diagram  (CFDD)  is  depicted  in  Figure 
36  and  contains  three  children  modules:  Manage  Personal  Information,  Apply  for  Vacant 
Positions  and  Employment  Search  Services  modules. 

The  Manage  Personal  Information  module  contains  eleven  use  cases,  which  are 
presented  in  Appendix  B,  and  it  focuses  on  the  candidate’s  career  management  tools. 
Within  this  module  the  candidate  is  allowed  to  create,  review,  update  and  delete  personal 
information  that  is  contained  in  their  Reserve  Qualification  Summary.  This  information 
that  is  modifiable  is  limited  to  the  candidate’s  employment  history  and  their  personal 
comments,  because  the  rest  of  the  data  is  autopopulated  from  Marine  Corps  Enterprise 
systems.  If  the  candidate  discovers  an  error  within  the  autopopulated  data  he  or  she  will 
have  to  utilize  official  Marine  Corps  channels  to  get  it  updated  (S-l  or  MOL).  This 
module  provides  the  candidate  with  the  ability  to  create,  review,  update  and  delete  their 
personal  web-portal  settings.  This  module  also  allows  them  to  participate  in  community 
events  such  as  blogs,  webinars  and  other  web  driven  resources  that  the  candidate  may 
desire  to  use.  External  Marine  Corps  services  and  the  candidate’s  ability  to  manage 
employment  leads  also  reside  in  this  module. 

The  Apply  for  Vacant  Position  module  allows  a  candidate  to  create,  review, 
update  and  delete  applications  that  they  submitted.  The  candidate  can  also  review  their 
application  history,  the  application  pool  for  an  active  advertisement,  contact  the  employer 
of  an  active  advertisement,  as  well  as,  manually  search  for  future  vacant  billets. 

The  Employment  Search  Services  allows  a  candidate  to  create,  review,  update  and 
delete  employment  search  subscriptions.  These  subscriptions  are  an  automated  service 
that  provides  the  user  with  the  matching  results  of  employment  queries  that  are  applied 
continuously  against  the  RBAS  data  repository.  These  services  are  voluntary  and  must 
be  signed  up  for  by  the  candidate. 
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Figure  36.  Candidate  Event  Decomposition  Diagram 


3.  Recruiter  Functional  Decomposition  Diagram 

The  Recruiter  Functional  Decomposition  Diagram  (RFDD)  is  depicted  in  Figure 
37  and  contains  three  children  modules:  Utilize  Candidate  Recruitment  Services,  Manage 
Web  Portal  Settings,  and  Recruitment  Management  Tools. 
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The  Utilize  Candidate  Recruitment  Module  contains  seven  use  cases  which  are 
included  in  Appendix  C.  This  module  provides  the  recruiter  with  the  ability  to  create, 
review,  update  and  delete  candidate  search  and  billet  search  subscription  services.  These 
subscriptions  are  an  automated  service  that  provides  the  user  with  the  matching  results  of 
candidate  and  employment  queries  that  are  applied  continuously  against  the  RBAS  data 
repository.  These  services  are  voluntary  and  must  be  signed  up  for  by  the  recruiter.  This 
module  also  provides  the  recruiter  with  the  ability  to  manually  search  for  billets  and 
candidates  as  well.  Additionally,  this  module  also  provides  the  recruiter  with  resources 
necessary  to  run  and  manage  community  events.  This  includes  services  such  as  webinars, 
blogs  and  instant  messaging. 

The  Manage  Web  Portal  allows  the  Recruiter  to  create,  review,  update  and  delete 
the  Recruiter’s  personal  web-portal  settings.  This  allows  the  recruiter  to  dynamically 
change  their  environment  to  suit  their  needs  and  desires.  This  customizable  interface 
would  allow  them  to  subscribe  to  Really  Simple  Syndication  (RSS)  broadcasts  which 
include  blog  entries,  news  headlines,  and  podcasts  in  a  standardized  format.  They  will 
also  be  able  to  modify  their  background,  install  web  widgets  and  view  results  of  RBAS 
subscription  notifications. 

The  Recruiter  Management  Tools  module  provides  the  Recruiter  with  the  ability 
to  generate  ad  hoc  reports,  manning  reports,  as  well  as,  the  ability  to  manage  the  leads 
generated  by  candidates  and  employers.  This  will  provide  the  recruiter  with  a  robust  set 
of  data  that  can  be  examined  for  trends  and  assist  the  recruiter  in  meeting  his  or  her 
assigned  mission. 
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4.  Management  Functional  Decomposition  Diagram 

The  Management  Functional  Decomposition  Diagram  (MFDD)  is  depicted  in 
Figure  38  and  contains  four  children  modules:  Manage  Reserve  Billet  Advertisement 
System,  Manage  User  Roles,  Generate  Managerial  Reports  and  Manage  Administrative 
Web  Portal. 

The  Manage  Reserve  Billet  Advertisement  System  includes  six  use  cases  in 
Appendix  D  that  focus  the  automated  functionality  and  the  interaction  with  Marine  Corps 
Enterprise  legacy  systems.  Specifically,  this  module  addresses  the  automated  population 
of  the  candidate  and  MOS  tables  of  the  database  from  the  MCTFS  and  TFSMS  systems. 
The  module  also  provides  the  Manager  with  the  ability  to  manage  trouble  calls,  verify 
user’s  credentials,  as  well  as,  perform  limited  maintenance  to  the  system.  The 
maintenance  that  the  Manager  can  perfonn  is  limited  to  items  that  do  not  affect  the 
nonnalization  of  the  database. 

The  Manage  User  Roles  module  allows  the  Manager  to  create,  review,  update  and 
delete  system  user  rights  and  privileges.  Through  this  module  the  manager  will  assign 
users  rights  and  responsibilities.  This  module  will  also  allow  managers  to  assign  the 
privileges  and  capabilities  of  the  different  access  roles  within  the  system. 

The  Generate  Managerial  Reports  module  allows  the  Manager  to  create  ad  hoc 
reports,  user  overview  reports,  system  usage  reports  and  a  detailed  user  report.  These 
managerial  reports  will  allow  the  manager  to  monitor  access  and  understand  the  different 
use  patterns  of  users  and  groups. 

The  Manage  Administrative  Web  Portal  module  provides  the  Manager  with  the 
tools  necessary  to  create,  review,  update  and  delete  the  Manager’s  personal  web-portal 
settings.  This  allows  the  manager  to  dynamically  change  their  environment  to  suit  their 
needs  and  desires.  This  customizable  interface  would  allow  them  to  subscribe  to  Really 
Simple  Syndication  (RSS)  broadcasts  which  include  blog  entries,  news  headlines,  and 
podcasts  in  a  standardized  format.  They  will  also  be  able  to  modify  their  background, 
install  web  widgets  and  view  results  of  RBAS  subscription  notifications. 
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D.  SYSTEM  DIAGRAMS 

The  final  step  of  our  methodology  is  to  stake  the  building  blocks,  the  event 
diagrams,  and  construct  the  sub-system  diagrams.  These  constructs  provide  the 
stakeholders  with  a  complete  picture  on  how  all  of  the  different  events  will  work 
together.  In  this  case,  due  the  size  of  the  system,  we  chose  to  construct  sub-system  vice  a 
complete  system.  A  complete  system  diagram  would  have  detracted  from  the  usefulness 
of  the  model.  Each  of  the  models  is  presented  immediately  following  this  introduction. 

The  first  model,  depicted  in  Figure  39,  is  the  Management  Sub-System  model.  It 
clearly  shows  that  this  sub-system  is  geared  towards  the  management  of  the  users  of  the 
system,  as  well  as,  the  functionality  of  the  system.  The  second  model,  depicted  in  Figure 
40,  is  the  Candidate  Sub-System.  This  sub-system  provides  the  candidate  with  a  robust 
set  of  tools  to  actively  manage  their  career.  The  third  model,  depicted  in  Figure  41,  is  the 
Employer  Sub-System.  This  sub-system  focuses  on  providing  the  employers  the  ability  to 
not  only  advertise  a  vacant  billet,  but  it  also  provides  them  with  a  proactive  set  of 
resources  that  they  can  use  to  search  for  candidates.  The  final  model,  depicted  in  Figure 
42,  is  the  Recruiter  Sub-System  model.  This  sub-system  provides  the  recruiter  with 
dynamic  capabilities  that  they  require  to  actively  pursue  candidates. 
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Figure  39.  Management  Subsystem  Diagram 
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Candidate  Sub-System  Diagram 
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Figure  4 1 .  Employment  Sub-System  Diagram 
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Recruiter  Sub-System  Diagram 
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V.  PROPOSED  SYSTEM  ARCHITECTURE  FOR  NEXT 
GENERATION  MARINE  CORPS  BILLET  ADVERTISEMENT 

SYSTEM 

The  previous  chapter  identified  and  defined  the  requirements  for  the  next  Marine 
Corps  Reserve  billet  advertisement  system.  This  chapter  expands  upon  requirement 
definition  by  presenting  a  generic  architecture  in  which  the  Marine  Corps  will  be  able  to 
build  their  new  system. 

To  achieve  that  objective,  this  chapter  is  organized  in  the  following  manner:  The 
Proposed  Architectural  Vision  and  Methodology  section  provides  the  readers  with  the  big 
picture,  examines  the  benefits  and  costs  associated  with  the  architectural  design  and 
concludes  with  the  methodology  used  to  for  the  development  of  the  system’s  generic 
architecture.  The  Proposed  Prototype  Architecture  section  presents  our  generic  high-level 
architecture.  The  Quality  Attribute  Tree  section  presents  readers  with  the  metrics  that  will 
be  used  to  measure  the  effectiveness  of  the  proposed  architecture.  The  Proposed  System 
section  will  build  an  instance  of  a  specific  system  using  the  generic  architecture.  Next, 
the  Architecture  Evaluation  Section  will  use  the  quality  attributes  to  gauge  the 
effectiveness  of  the  proposed  system.  Finally,  the  Risk  Management  Section  will  address 
the  most  significant  risks  to  the  proposed  generic  architecture. 

A.  PROPOSED  ARCHITECTURAL  VISION  AND  METHODOLOGY 

1.  Architectural  Topology  Selection 

During  the  analysis  of  the  results  of  the  literature  review  and  requirements 
analysis  viable  architectural  patterns,  frameworks  and  components  were  discovered  and 
incorporated  into  the  future  system  design.  Specifically,  it  was  detennined  that  all  of  the 
systems  analyzed  were  built  from  a  variation  of  a  hub  and  spoke  architecture  and  that 
they  used  the  Internet  as  the  primary  medium  to  connect  the  system  to  its  users. 

2.  The  Vision 

From  these  findings,  we  were  able  to  develop  a  Software  Product  Fine  (SPF)  with 

a  specified  Product  Fine  Architecture  (PLA)  that  addresses  the  needs  of  the  future  Marine 
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Corps  billet  advertisement  system.  This  SPL  not  only  helps  the  Marine  Corps,  but  it  will 
also  extend  to  any  component  of  the  DoD  that  needs  to  build  a  dynamic  billet 
advertisement  system.  According  to  Ian  Gorton’s  book  Essential  Software  Architecture 
an  SPL  is  a  collection  of  related  products  developed  by  combining  core  assets  with 
product-specific  assets  that  vary  the  functionality  of  the  core  assets,  and  a  PLA  is  a  reuse- 
oriented  architecture  for  the  core  assets  of  the  SPL  [26].  This  reusable  solution  would 
address  many  other  problems  within  the  DoD  and  not  just  that  of  the  Marine  Corps 
Reserve.  For  instance,  the  SPL  would  not  only  solve  the  Marine  Corps  quandary  on  how 
to  build  an  adequate  billet  advertisement  system,  it  also  addresses  similar  problems 
experienced  by  other  components  of  DoD  that  need  to  advertise  and  fill  billets  of  any 
type.  A  great  example  of  this  would  be  the  military  school  houses  and  training  centers 
which  are  driven  by  filling  and  managing  billets  within  their  respective  commands.  Both 
of  these  commands  could  use  the  SPL  to  quickly  build  a  dynamic  billet  advertisement 
system  at  a  much  lower  cost  than  building  it  autonomously.  The  potential  for  this  type  of 
SPL  for  the  DoD  is  boundless  as  the  majority  of  all  military  personnel  management  and 
training  systems  are  driven  by  billets  that  need  to  be  filled  and  advertised. 

3.  Software  Product  Line  Benefits 

There  are  many  benefits  to  leveraging  an  SPL.  First  and  foremost  it  would  save 
the  DoD  significant  amounts  of  money,  and  second  it  would  reduce  the  manpower  and 
efforts  required  to  build  a  new  products  because  of  the  reuse  of  software  products  [4]. 
Specifically,  an  SPL  will  save  DoD  money  in  the  building  process  because  the  design  of 
each  new  specialized  variant  requires  less  time  and  money  to  implement  the  new  asset. 
This  would  reduce  costs  to  the  DoD  considerably.  An  SPL  would  also  save  money  due  to 
the  reduced  costs  of  maintaining  the  systems  [4],  For  instance,  if  a  piece  of  software 
contained  in  the  SPL  was  upgraded,  the  cost  of  the  upgrade  is  distributed  over  all  users  of 
the  SPL.  In  its  current  configuration  of  isolated  and  stovepipe  systems,  the  DoD  has  to 
pay  for  the  same  type  of  upgrade  for  each  system  individually  rather  than  distributing  the 
cost  across  all  of  the  systems.  This  is  a  significant  expenditure.  These  points  make  it 
blatantly  obvious  that  the  DoD  is  incurring  a  lot  of  unnecessary  expenses  that  are 
mitigated  by  using  an  SPL. 
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Leveraging  an  SPL  would  not  only  save  the  DoD  money,  it  would  also  free  up 
manpower  and  resources  by  reusing  a  product.  An  SPL  would  reduce  manpower 
requirements  because  it  eliminates  numerous  duplicated  managerial  and  maintenance 
efforts  that  are  associated  with  stovepipe  systems.  For  example,  currently  each  agency 
within  the  DoD  manages  the  life  cycle  of  each  of  its  different  billet  advertisement 
systems.  This  correlates  to  many  redundant  and  duplicated  efforts  by  a  large  body  of 
managers.  An  SPL  also  reduces  maintenance  requirements  because  of  the  common 
architecture  being  leveraged.  This  reduction  would  be  apparent  if  the  DoD  converted  all 
of  their  billet  advertisement  systems  to  an  SPL  built  on  a  common  PLA,  because  the  life- 
cycle  management  becomes  considerably  easier  and  less  manpower  intensive  because  the 
core  of  each  system  is  now  the  same. 

4.  Concerns  and  Issues 

These  arguments  make  it  easy  to  see  why  utilization  of  an  SPL  is  beneficial,  but 
there  are  some  concerns  for  building  a  SPL.  For  the  remainder  of  this  section  we  briefly 
discuss  a  few  of  the  high  level  concerns,  followed  by  a  description  of  how  the  proposed 
system  is  tested.  As  with  any  SPL  an  architect  is  concerned  about  defining  the  scope  and 
the  market  of  a  system.  In  this  case,  each  of  the  systems  that  we  reviewed  all  had  similar 
scope,  and  the  market  of  the  new  SPL  is  simple  -  the  DoD.  We  are  not  trying  to  trivialize 
these  two  problem  concerns  (scope  and  market),  but  because  of  the  unique  environment 
in  which  this  SPL  is  being  built  they  are  much  easier  to  get  a  handle  on  than  in  a 
commercial  environment.  Gorton  identified  three  other  factors  that  may  act  as  “barriers” 
to  an  organization  adopting  an  SPL,  and  we  consider  these  briefly.  These  areas  are: 
change  of  control  issues,  the  definition  of  core  attributes  and  the  design  of  the  PLA  [4]. 

Change  of  control  issues  spawn  from  the  stakeholder’s  reluctance  or  fear  to 
relinquish  their  power  and  control  over  their  systems.  For  example,  within  DoD  every 
service  wants  control  over  the  purse  strings  of  their  IT  systems,  because  this  provides 
them  with  the  ability  to  manage  and  shape  the  system  as  they  see  fit.  This  thought  process 
is  fractured  because  it  leads  to  the  services  duplicating  their  efforts  and  poorly  designed 
systems.  This  is  evident  in  DoD  as  each  service  has  built  its  own  billet  advertisement 
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system,  all  of  these  systems  are  severely  flawed  and  each  service  pays  more  than  it  needs 
to  maintain  its  system  because  each  one  incurs  all  the  costs  itself.  Stakeholder  interviews 
revealed  that  each  of  the  services  understand  that  its  system  is  incomplete  and  each 
identified  the  need  for  a  more  complete  system,  but  even  with  this  omission  none  of  the 
services  want  to  relinquish  control  by  building  a  joint  system  billet  advertisement  system. 
The  next  problem  identified  by  Gorton  is  how  to  determine  what  the  core  attributes  for 
the  proposed  SPL  are.  In  this  case  a  thorough  review  of  requirements  documents  and 
stakeholder  interviews  captured  the  majority  of  these  attributes.  The  initial  results  were 
presented  to  the  stakeholders  for  review  and  approval  which  they  acknowledged.  The  last 
problem  discussed  by  Gorton  was  system  design.  The  design  will  focus  on  the  core 
attributes  identified  through  requirements  analysis.  Stakeholder  interviews  also  identified 
all  of  the  variations  required  by  the  different  products.  Understanding  this  “variation”  is 
important  when  designing  a  PLA,  because  the  design  of  the  PLA  must  ensure  that  these 
variances  are  compatible  with  the  core  attributes. 

5.  Strategic  Methodology  -  The  Way  Forward 

To  prove  the  concept  that  a  SPL  is  sound  and  that  the  vision  has  merit,  we  are 
going  to  apply  this  vision  to  our  original  problem  domain  of  advertising  and  filling  billets 
for  the  Marine  Corps  Reserve.  The  system  built  from  the  proposed  generic  architecture 
will  be  validated  and  tested  against  stakeholder  defined  metrics,  quality  attributes,  to 
measure  the  effectiveness  of  the  proposed  architecture.  This  process  is  depicted  in  Figure 
43. 

The  generic  architecture  was  designed  using  a  hybrid  version  of  the  FAST  and 
ATAM  methodologies  to  perform  our  analysis.  In  this  chapter  we  used  steps  four  through 
eight  of  the  ATAM  methodology,  a  brief  description  of  each  follows. 

Step  four  of  the  ATAM  methodology  expands  upon  step  three  by  describing  the 
generic  components,  the  topology  and  the  framework  in  detail.  Step  five  generates  the 
Quality  Attribute  Utility  Tree.  The  Quality  Attribute  Utility  Tree  identifies  and  prioritizes 
the  system’s  most  important  quality  attributes  [3].  The  output  of  this  tree  generates 
specific  quality  attributes  in  the  form  of  scenarios.  Step  six  through  eight  leverage  the 
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scenarios  generated  by  the  utility  tree.  The  scenarios  are  used  to  rank  and  analyze  the 
different  quality  attributes,  which  allows  the  architect  to  focus  on  the  final  architecture 
and  the  construction  of  the  product. 
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Figure  43.  Strategic  Overview  Methodology 
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B. 


PROPOSED  PROTOTYPE  ARCHITECTURE 


1.  Generic  Product  Line  Architecture 

Our  first  step  was  to  build  a  generic  PLA.  Figure  44  contains  a  depiction  of  this 
high-level  generic  architecture  we  built.  This  architecture  captures  the  essence  of  the 
framework  required  for  any  billet  advertisement  system  utilized  by  any  DoD  component. 
The  natural  layout  of  this  high-level  architecture  correlates  to  a  hub-and-spoke 


architecture  which  maximizes  the  connectivity  between  the  front-end  users  and  the  back- 


Figure  44.  Generic  High  Level  Architecture 


end  legacy  systems  by  decoupling  the  systems.  Decoupling  the  systems  allows  the 
different  systems  to  continue  to  utilize  their  programming  language  and  data  structures, 
because  they  send  their  output  in  its  natural  form  to  the  centralized  hub  which  contains 
definition  and  transformation  logic  that  is  used  to  convert  the  messages  into  a  common 
format  [3]. 
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2.  Billet  Advertisement  System  Module  (BASM) 

The  “hub”  of  this  architecture  is  the  Billet  Advertisement  System  Module 
(BASM),  because  this  module  connects  all  of  the  different  resources  and  modules  and 
drives  the  entire  process  flow.  The  BASM  will  automate  the  job  vacancy  advertisement 
process  by  drawing  and  comparing  information  that  is  contained  in  the  different 
personnel  and  planning  infonnation  warehouses.  BASM  will  also  provide  all  of  the 
management  services,  ad  hoc  management  report  generation  capabilities  and  web 
services  for  the  system.  This  module  will  also  enforce  all  expiry  dates  to  minimize  the 
amount  of  dirty  data  that  is  stored  in  the  data  repositories. 

The  BASM  acts  as  the  “hub”  all  other  modules  are  dependent  upon  it,  therefore, 
the  reliability  and  performance  of  the  BASM  is  paramount  to  the  success  of  the  system. 
That  being  said,  the  BASM’s  primary  quality  attributes  are  system  availability  and 
system  throughput.  To  meet  this  requirement  the  BASM  must  be  available  to  its  users 
greater  than  99  percent  of  the  time,  and  it  will  handle,  at  a  minimum,  100  billet  query 
messages  per  second  during  peak  usage  periods.  The  BASM  will  incorporate  robust  and 
redundant  mirror  sites  that  will  share  the  transaction  load,  as  well  as,  pick  up  the  load  if 
one  of  the  systems  should  fail  to  ensure  that  further  ensure  that  the  availability  quality 
attribute  is  met.  The  requirements  discovery  also  identified  that  the  BASM  must  be 
modifiable  due  to  the  constant  evolution  of  military  organizations.  To  address  this 
requirement  the  BASM  will  provide  system  administrators  with  the  ability  to  make 
changes  to  the  aesthetics  of  the  system,  as  well  as,  the  ability  to  change  nomenclature. 
This  will  allow  the  site  to  remain  fresh  and  accurate  without  compromising  the  integrity 
of  the  system.  The  BASM  will  also  provide  the  user  with  a  robust  set  of  career  and 
management  tools.  These  tools  will  allow  the  reservist  to  actively  manage  their  career, 
and  they  will  provide  system  managers  and  employers  with  ad  hoc  report  capabilities,  as 
well  as,  administrative  tools.  Connected  to  the  hub  in  this  star  topology  are  four  core 
modules:  the  Recruiter  Module  (RM),  the  Employment  Module  (EM),  the  Candidate 
Module  (CM)  and  the  Data  Module  (DM). 
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3.  Recruiter  Module  (RM) 

The  RM  provides  job  recruiters  with  a  portal  in  which  they  can  tap  the  resources 
of  the  BASM,  receive  direction  from  the  various  employers  using  the  system,  as  well  as, 
receive  leads  generated  by  the  interaction  of  applicants  with  the  system.  The  RM  will  use 
HTTP/HTTPS  and  FTP/FTPS  via  the  Internet  as  its  primary  means  of  passing 
information  to  and  from  the  BASM.  The  RM’s  primary  quality  attributes  are 
accessibility  and  security.  Due  to  the  mobile  nature  of  a  “recruiter”  accessibility  to  the 
system  is  paramount.  Therefore,  the  RM  will  be  accessible  via  several  access  methods, 
including,  but  not  limited  to,  mobile  devices  such  as  PDAs,  cell  phones  and  laptops.  In 
order  to  meet  this  quality  attribute  the  architecture  will  handle  messages  transmitted  over 
different  channels  such  as  the  Internet  using  a  SOAP  message  protocol.  The  RM  will  also 
provide  a  large  tool  bag  of  web  tools  such  as  blogs,  email,  cellular  technologies  and 
instant  messaging.  These  “tools”  will  maximize  the  connectivity  and  accessibility  with 
potential  applicants.  Because  of  the  number  of  ways  a  user  connects  to  the  system, 
security  is  a  significant  concern.  Firewalls,  virus-protection  and  identity  management  will 
be  built  into  the  architecture  to  mitigate  much  of  the  risk  posed  by  these  mobile  users. 

4.  Employer  Module  (EM) 

The  EM  provides  the  different  employers  with  a  portal  in  which  they  can 
advertise  job  vacancies,  actively  manage  the  hiring  process  and  search  for  potential 
candidates  of  interest.  This  portal  will  also  provide  a  conduit  in  which  they  can  actively 
drive  the  recruiters’  efforts  by  prioritizing  the  job  postings  dynamically.  The  EM’s 
primary  quality  attributes  are  usability  and  authorization.  The  architecture  is  designed  to 
make  the  process  as  simple  as  possible  for  Employers,  i.e.  more  usable.  For  example,  an 
employer  will  receive  real-time  updates  to  changes  that  affect  the  candidate  pool,  such  as 
when  applicants  withdraw  their  applications  from  the  queue.  This  will  allow  employers  to 
make  more  informed  decisions  during  the  hiring  process.  Employers  can  also  contact 
potential  applicants  via  email  or  instant  messaging  in  order  to  request  additional 
information.  Authorization  must  be  aggressively  addressed,  because  of  the  employer’s 
access  to  personal  and  professional  information  of  candidates.  To  ensure  this  quality 
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attribute  is  meet  system  administrators  will  grant  and  manage  employer’s  access  to  the 
system.  Beyond  usability  and  authorization,  because  the  employers  are  accessing 
individuals’  personal  data,  security  is  critical.  Therefore,  when  private  data  is  accessed, 
the  system  will  use  encrypted  SOAP  messages  over  HTTPS  or  FTPS.  If  the  size  of 
SOAP  messages  becomes  an  issue  due  to  system  constraints,  other  more  compact  binary 
message  formats  such  as  CORBA,  GIOP,  or  ICE  will  be  utilized.  Also,  transactional 
integrity  must  also  be  guaranteed;  to  do  this,  the  system  will  lock  the  job  management 
resources  until  it  receives  a  positive  response  from  the  BASM  that  acknowledges 
successful  completion  of  the  transaction. 

5.  Candidate  Module  (CM) 

The  CM  provides  a  portal  in  which  all  applicants  are  able  to  search  and  apply  for 
vacant  positions  advertised  by  their  DoD  force.  The  AM’s  primary  quality  attributes  are 
usability  and  security.  Specifically,  the  system’s  usability  is  enhanced  by:  First, 
applicants  can  monitor  the  state  of  a  current  application,  view  their  previous  work  history 
or  modify  or  delete  any  application  that  has  not  already  been  reviewed  by  the  potential 
employer.  Second,  applicants  are  able  to  leverage  dynamic  resources  in  which  they  can 
manage  their  personal  and  professional  infonnation.  Third,  applicants  can  join  a 
“community”  where  they  are  able  to  discuss  matters  which  interest  them  with  other 
members  in  order  to  induce  networking  and  a  sense  of  belonging.  Again,  because  the 
sensitivity  of  the  information  being  submitted  by  the  applicant,  the  importance  of  security 
is  paramount.  Therefore,  just  as  in  the  EM  module,  measures  such  as  using  encrypted 
SOAP  messaging  over  HTTPS  or  FTPS  are  built  into  the  system  to  ensure  the  safety  of 
private  information  being  submitted  by  the  user.  And  also  like  the  EM,  transactional 
integrity  must  be  guaranteed  in  the  CM;  to  do  this,  the  system  will  lock  the  application 
resources  until  it  receives  a  positive  response  from  the  BASM  that  acknowledges 
successful  completion  of  the  transaction. 

C.  QUALITY  ATTRIBUTE  UTILITY  TREE 

Following  the  specification  of  the  high-level  architecture,  a  detailed  stakeholder 
analysis  was  conducted  to  determine  the  “wish  lists”  for  the  system.  This  analysis 
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included  stakeholder  interviews,  literature  review,  as  well  as,  a  thorough  analysis  of  the 
current  iteration  of  RDOL.  These  efforts  led  to  the  definition  of  the  required  quality 
attributes  of  the  system,  which  were  inserted  into  “a  utility  tree”  or  “a  quality  attribute 
tree,”  (Figures  45  through  47)  to  make  it  easy  to  understand  and  digest.  This  step  is 
particularly  important,  because  quality  attribute  utility  trees  focus  efforts  on  the  aspects 
of  architecture  that  are  critical  to  the  success  of  the  system  [26],  The  developed  tree, 
while  not  all  inclusive,  does  just  that  as  it  includes  the  attributes  that  were  deemed  by  the 
stakeholders  of  the  system  as  most  important.  They  include  the  following  critical 
attributes:  timeliness,  automation,  modifiability,  integration,  security,  usability  and 
availability. 

The  following  is  a  brief  description  of  the  high-level  quality  attributes  that  were 
defined  by  the  stakeholders.  The  timeliness  attribute  defines  how  the  age  of  an 
advertisement  affects  the  viability  of  the  data.  The  automation  attribute  addresses  how 
data  and  when  data  is  transferred  to  the  advertisement  system,  what  data  sources  are 
utilized  and  how  the  information  is  coalesced  and  processed.  The  modifiability  attribute 
defines  how  the  system  is  configured,  how  it  will  respond  to  growth  and  how  it  will  scale 
to  increased  use. 
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Figure  45.  Quality  Attribute  Tree  (Top  Section) 


The  integration  attribute  defines  the  interoperability  of  the  system  with  other 
systems  and  how  it  will  communicate  with  them.  The  security  attributes  identifies  how 
the  system  will  authenticate  and  authorize  resources  to  its  users.  It  also  defines  the 
requirements  on  how  the  system  will  guarantee  the  integrity  of  the  data  being  transmitted 
between  systems. 
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Figure  46.  Quality  Attribute  Tree  (Middle  Section) 

The  usability  attribute  defines  what  tools  are  available  to  reservists  and  managers, 
and  it  defines  how  data  is  structured  as  the  user  inputs  information  into  forms.  Finally, 
the  availability  attribute  will  define  aspirations  for  uptime  and  accessibility,  which  will 
ultimately  affect  the  hardware  and  redundancy  qualities  of  the  system. 
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Figure  47.  Quality  Attribute  Tree  (Bottom  Section) 


D.  PROPOSED  SYSTEM 

After  analyzing  the  required  quality  attributes  and  reviewing  the  generic  high- 
level  architecture,  the  next  step  in  our  process  was  to  build  a  specialized  instance  of  this 
generic  architecture.  Every  component  within  this  specific  system  correlates  directly  to  a 
generic  component  within  the  PLA.  It  was  determined  that  leveraging  the  robustness  of 
commercial  components  by  plugging  them  into  our  generic  architecture  provided  the  best 
solution  for  the  Marine  Corps.  This  decision  was  made  because  the  billet  advertisement 
systems  currently  deployed  by  the  DoD  failed  to  meet  the  litmus  test  due  to  poor  design, 
lack  of  documentation  and  inadequate  management.  For  example,  the  JOAPPLY  system 
deployed  by  the  Naval  Reserve  was  built  iteratively  from  a  small  Excel  worksheet.  As  the 
system  grew,  system  administrators  failed  to  document  the  changes  that  were  made  to  the 
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system  which  led  to  significant  compatibility  issues,  as  well  as,  major  scaling  issues.  This 
“no  plan”  type  build  has  led  not  only  to  technical  issues,  but  also  led  to  significant 
maintenance  costs.  This  type  of  problem  was  indicative  of  every  DoD  system  that  we 
analyzed. 

Therefore,  it  was  concluded  that  building  a  hybrid  system  by  integrating 
Monster.com’s  commercial  architecture  within  the  generic  architecture  provided  the  most 
complete  and  viable  solution.  This  approach  prevents  the  DoD  from  “reinventing  the 
wheel,”  because  it  uses  existing  and  proven  commercial  technologies.  It  also  minimizes 
life-cycle  maintenance  costs;  because  the  primary  billet  search  system  is  already  mature 
and  has  been  optimized.  In  addition,  it  affords  the  DoD  with  the  best  opportunity  to  get  a 
system  up  and  running  the  quickest.  Figure  48  presents  a  high-level  view  of  the  hybrid 
architecture  that  we  propose  that  the  Marine  Corps  adopt  and  deploy.  This  system  was 
built  from  the  framework  of  the  generic  architecture  proposed  earlier  in  this  paper;  that 
being  said,  we  will  emphasize  this  point  by  breaking  each  component  down  and  tying  it 
back  to  the  corresponding  component  in  the  generic  architecture.  The  “hub”  of  the 
generic  architecture  is  the  BASM.  With  this  proposed  instantiation  the  functionality  and 
responsibilities  of  the  BASM  is  distributed  over  five  modules:  the  Application  Module, 
the  Monster  Business  Gateway,  Marine  Corps  Recruitment  System  (MCRS),  Marine 
Corps  Employer  Agency  System  (MCEAS)  and  the  Marine  Corps  Reserve  Management 
System.  We  breakdown  the  system  based  on  these  three  components. 
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Figure  48.  High-Level  View  of  Proposed  System 


1.  Application  Module 

The  Application  Module  captures  all  the  quality  attributes  defined  for  the  AM 
module  in  the  generic  architecture,  but  it  also  inherits  the  community  socialization  tools 
that  were  originally  assigned  to  the  BASM.  In  fact,  the  Applicant  Module  is  where  the 
primary  front-end  users  interact  with  the  system,  and  it  is  completely  contained  within  the 
domain  of  the  Monster.com  portion  of  the  system.  The  reason  for  this  is  simple:  Monster 
knows  what  it  is  doing  on  the  front-end.  Monster,  in  its  current  configuration,  has  17 
unique  job  search  networks  and  40  international  sites  which  encompass  both  commercial 
and  academic  institution  portals  [27].  This  congregation  of  resources  has  created  an 
impressive  data  warehouse  of  potential  candidates,  in  fact,  as  of  June  2007,  Monster  and 
its  subsidiaries  housed  over  80  million  unique  job  seeker  resumes  and  40,000  more  are 
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added  each  day  [28].  This  makes  it  easy  to  surmise  that  they  are  able  to  handle  the 
increased  volume  of  consumers  that  Marine  Corps  Reservists  will  introduce  to  their 
system. 


Figure  49.  Monster  Business  Gateway  Component  View 


2.  Monster  Business  Gateway  (BGW) 

The  Monster  Business  Gateway  (BGW),  depicted  in  Figure  49,  is  the  next  module 
analyzed.  The  BGW  will  act  as  the  sole  interface  and  the  hub  between  Monster.com 
resources  and  the  Marine  Corps  systems.  Therefore,  this  component  takes  much  of  the 
messaging  responsibilities  that  were  delineated  for  the  BASM  presented  in  the  generic 
high-level  architecture.  Specifically,  it  will  pass  all  information  between  the  different 
spokes  of  the  hub  and  spoke  architecture.  Messages  to  and  from  the  BGW  will  support 
SOAP  XML  requests  over  HTTP/FITTPS  or  FTP/FTPS.  The  SOAP  header  will  contain  a 
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time  stamp,  a  unique  message  ID  and  an  authentication  ticket  [20].  The  combination  of 
HTTPS/FTPS  protocols  and  the  SOAP  header  contents  address  the  security  quality 
attribute  requirements.  Information  transferred  internally  within  Monster  is  distributed  by 
application  servers  which  will  disseminate  the  data  to  the  appropriate  component  within 
Monster.  The  BGW  has  multiple  mirror  sites  and  Monster  guarantees  over  99  percent 
availability  for  this  resource.  The  BGW  can  also  handle  over  1000  transactions  per 
second  [20].  Both  of  these  results  exceed  the  accessibility  and  throughput  quality 
attribute  requirements  that  were  defined  in  the  BASM  portion  of  the  generic  architecture. 
All  transaction  requests  submitted  or  received  via  the  BGW  are  positively  acknowledged 
near  real-time  depending  on  the  size  of  the  file  being  transferred. 


Figure  50.  Marine  Corps  Reserve  Management  System  Component  View 
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3.  Marine  Corps  Reserve  Management  System  (MCRMS) 

Figure  50  depicts  the  Marine  Corps  Reserve  Management  System  (MCRMS),  and 
it  contains  the  last  of  the  distributed  attributes  of  the  BASM  from  the  generic  high-level 
architecture.  Specifically,  this  module  will  provide  the  automation  and  management  tools 
that  were  originally  the  responsibility  of  the  BASM.  This  component  is  built  using  a  three 
tier  architecture  that  is  housed  at  Headquarters  Marine  Corps  with  a  mirrored  sight 
maintained  at  MARFORRES  in  New  Orleans.  The  top  layer,  the  Web  Services  Tier,  is 
located  within  the  Demilitarized  Zone  (DMZ)  of  the  Marine  Corps  domain.  Its  purpose  is 
to  unwrap  or  wrap  data  in  an  appropriate  SOAP  wrapper  and  transmit  it  to  the 
Application  tier  or  the  BGW  for  processing.  The  bottom  layer,  the  Marine  Corps 
Enterprise  Data  Warehouse  Tier,  is  currently  comprised  of  numerous  legacy  systems  that 
operate  autonomously.  This  layer  is  conceptually  made  of  up  of  the  Marine  Corps  Total 
Force  System  (MCTFS)  and  Total  Force  Manpower  Models  Reengineering  System 
(TFMRS).  MCTFS,  the  Marine  Corps  personnel  system,  houses  all  of  the  personal  data 
and  assignment  history  of  current  and  past  Marine  Corps  personnel.  TFMRS,  the  Marine 
Corps  manpower  modeling  system,  houses  all  of  the  Marine  Corps  present  and  future 
manning  models.  The  top  and  bottom  tiers  are  connected  to  the  application  layer  of  the 
MCRMS  via  the  Marine  Corps  secure  LAN. 

The  Application  Tier,  the  middle  component,  will  contain  a  Billet  Calculation 
module,  a  Resume  Information  module  and  a  Reservist  Management  module.  The  Billet 
Calculation  model  will  query  current  Table  of  Organization  data  for  a  specific  Reporting 
Unit  Code  (RUC)  from  TFMRS,  and  it  will  query  for  current  Marines  on  hand  for  the 
same  RUC.  The  application  will  then  determine  which  billets  are  vacant  for  that  RUC  by 
looking  for  disparities  between  the  two  sets  of  data.  This  functionality  meets  the 
requirement  defined  by  the  timeliness  quality  attribute  defined  in  the  Quality  Attribute 
Tree.  The  Resume  Infonnation  Module  will  query  data  from  MCTFS  to  auto-populate 
resume  fields.  This  attribute  meets  the  requirement  defined  by  Billet  Management  quality 
attribute  defined  in  the  Quality  Attribute  Tree.  The  Reservist  Management  Module  will 
allow  authorized  users  to  make  modifications  to  the  site,  create  on  demand  reports  and 


90 


assign  user  roles.  This  application  is  provided  by  Monster.  The  results  of  any  queries  are 
transmitted  to  the  Monster  site  via  the  Web  Services  Tier  which  will  send  it  to  the  BGW. 


Figure  5 1 .  Marine  Corps  Recruitment  Systems  Component  View 


4.  Marine  Corps  Recruitment  System  (MCRS) 

Figure  51  depicts  the  Marine  Corps  Recruitment  System  (MCRS)  which  provides 
the  Recruiters  with  a  robust  set  of  tools  in  which  they  can  leverage  leads  generated  by 
reservists  that  visit  the  Monster  website.  It  correlates  directly  to  the  Recruiter  Module  of 
the  generic  high-level  architecture.  The  MCRS  is  comprised  of  a  three  tier  architecture 
that  is  housed  at  Headquarters  Marine  Corps  with  a  mirror  site  at  the  West  Coast 
Regional  Recruiting  Office.  The  top  layer,  the  Web  Services  Tier,  resides  in  the  DMZ  on 
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the  Marines  domain  the  same  as  the  MCRMS  system.  The  recruiting  data  warehouse  is 
comprised  of  a  proprietary  data  warehouse  that  is  maintained  by  Marine  Corps  Recruiting 
Command. 

Due  to  the  breadth  and  dispersed  nature  of  recruiters,  this  node  is  accessible 
remotely  via  VPN  or  remote  access  point  via  any  peripheral  device  that  has  access  to  the 
Internet  and  has  encryption  capabilities.  That  application  tier  will  house  Monster  software 
that  will  allow  them  to  remotely  logon  to  the  site,  use  management  tools  and  leverage 
recruitment  tools.  This  Monster  application  will  also  facilitate  the  broadcasting  of  leads 
to  recruiters  near  real-time.  Specifically,  when  a  reservist  expresses  interest  in  a  billet,  a 
lead  is  generated  by  Monster  and  transmitted  to  the  Recruiters  automatically.  “Interest”  is 
defined  as  anyone  who  submits  a  resume,  or  anyone  who  submits  an  application  or 
anyone  who  request  additional  information.  This  is  relayed  via  the  gateway  to  the  web 
server  and  finally  to  the  application  server  which  then  disseminates  the  information  to  the 
various  devices  held  by  the  recruiter  closest  to  the  prospect.  Because  of  this,  the  module 
meets  the  accessibility  quality  attribute  that  was  defined  by  the  generic  architecture  and 
the  quality  attribute  tree.  Moreover,  this  module  meets  the  security  quality  attribute 
because  all  infonnation  transmitted  between  the  remote  user  and  the  MCRS  is  sent  via 
HTTPS  and  is  encrypted.  Users  also  have  the  ability  to  use  VPN  services  to  further 
secure  their  communication. 
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Figure  52.  Marine  Corps  Employer  Agency  Systems  Component  View 


5.  Marine  Corps  Employer  Agency  System  (MCEAS) 

Figure  52  depicts  the  Marine  Corps  Employer  Agency  System  (MCEAS).  This 
node  provides  employers  with  the  tools  and  resources  necessary  to  advertise  vacant 
billets,  as  well  as,  search  for  potential  candidates.  It  correlates  directly  with  Employer 
Module  from  the  generic  high-level  architecture,  and  it  meets  all  the  quality  attributes 
defined  by  the  Employer  Module.  This  node  of  the  system  is  also  built  upon  a  three-tier 
architecture.  The  top  layer  resides  in  the  DMZ  the  same  as  the  previous  two  systems.  The 
bottom  tier  is  comprised  of  numerous  data  warehouses  that  currently  reside  in  the 
different  stove  pipe  systems  that  exist  within  the  Marine  Corps.  No  queries  are  applied 
against  these  data  sources,  but  the  connectivity  is  established  for  future  application 
possibilities.  Monster  will  provide  the  application  that  allows  employers  access  to  the 
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new  system.  This  application  will  allow  them  to  build  and  manage  advertisements,  track 
and  monitor  response  and  review  resumes.  It  will  tie  back  to  the  system  via  the  BGW. 


E.  ARCHITECTURE  EVALUATION 

Using  the  Quality  Attributes  (QA)  identified  earlier,  we  evaluate  the  proposed 
system  that  was  built  using  the  generic  architecture.  QAs  represent  the  metric,  as  defined 
by  the  stakeholders  that  are  used  to  measure  the  viability  of  the  proposed  architecture. 
QAs  are  inserted  into  a  hierarchical  tree,  and  each  branch  of  the  tree  represents  a  QA.  The 
leaves  of  each  QA  branch  represent  scenarios  that  are  used  to  qualify  the  desired  level,  to 
operationalize  the  meaning  of  the  quality  in  practical  contexts,  and  to  evaluate  whether 
the  architecture  meets  the  needs  defined.  However,  we  will  only  address  four  scenarios, 
tied  to  particular  aspects  of  the  architecture  due  to  broad  scope  of  the  project  and  limited 
manpower. 

The  first  scenario  ensures  that  a  Manager  can  make  changes  to  the  system  as 
nomenclature  and  requirements  change  within  the  DoD.  The  military  undergoes 
continuous  change,  therefore  its  systems  must  adapt  with  them  or  they  will  become 
antiquated  well  before  their  project  useful  life.  The  second  scenario  ensures  that  the  jobs 
posted  within  the  site  are  viable  and  accurate.  In  the  past,  many  of  DoD  systems  did  not 
have  any  business  rules  in  place  to  ensure  that  the  data  being  displayed  was  within 
periodicity  or  that  the  information  being  displayed  was  correct.  The  third  scenario  tests 
the  connectivity  between  the  new  system  and  the  legacy  systems  within  the  Marine 
Corps.  This  is  significant,  because  all  of  the  data  repositories  that  our  drawn  from  all  are 
built  from  older  technologies.  The  fourth  scenario  ensures  that  reservists  can  actually 
search  for  prospective  employment.  If  this  function  doesn’t  work,  the  system  doesn’t 
work. 
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Scenario  #: 

1 

Scenario: 

Assigned  management  personnel  (military  or  civilian)  with  level  one  computer  skills, 

inputs  new  broadcast  message,  or  modifies  webpage  aesthetics  (front-end). 

Attribute(s): 

Modifiability 

Environment: 

Normal  Operating  Conditions. 

Stimulus: 

System  manager  desires  to  update  the  broadcast  message  on  the  site’s  homepage  to 

disseminate  information  to  all  current  users  without  the  use  of  spam. 

Response: 

A  broadcast  message  is  sent  to  all  applicable  recipients. 

Architectural 

decisions: 

The  key  architectural  decision  made  was  the  manner  in  which  broadcasts  are 

transmitted  to  the  desired  audience.  In  this  instance,  messages  are  transmitted  via  the 

BGW  and  posted  in  an  ALERT  section  of  the  user’s  homepage  for  review. 

Reasoning: 

Stakeholders  expressed  the  desire  for  a  Manager  to  log  onto  the  system  and  broadcast 

informational  messages  without  the  help  an  IT  professional.  They  also  expressed  a 

desire  to  limit  the  amount  of  information  that  was  transmitted  via  email.  Therefore 

ALERT  messaging  using  SOAP  was  selected  as  the  means  to  broadcast  messages  to 

users  of  the  system. 

Diagram: 

(verbal  description) 

In  this  scenario,  the  RDOL  manager  begins  by  successfully  logging  into  RDOL  with 

the  appropriate  privileges  to  make  changes.  He  or  she  would  then  enter  the  reserve 

management  module  and  creates  a  message.  Once  the  message  is  complete  and  the 

user  hits  “post  message.”  it  is  wrapped  in  a  SOAP  wrapper,  passed  to  the  web  services 

layer,  and  then  transmitted  via  HTTPS  to  Monster  via  the  Business  Gateway.  The 

BGW  submits  it  to  the  appropriate  application  within  the  monster  domain.  Upon 

successful  submission,  a  positive  response  is  presented  to  the  user  via  email/popup. 

Diagram: 

(pictorial  presentation) 

^  oS  iy 

Positive  bro 
confirmation  r 
sent  to  cr 

System  Reserve  Message  Monster.com 

Manager  Management  Application  BGW 

System 
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Analysis: 


As  this  system  is  largely  unchanged  since  its  inception  in  2001,  many  stakeholders 
wanted  minor  adjustments  to  the  website  front  end  (CSS  modifications)  or  simply  the 
manner  in  which  the  page  was  laid  out  (tabs,  menu  style).  The  current  iteration  of 
RDOL  requires  thousands  of  dollars  and  numerous  man  hours  to  make  even  the 
slightest  change  to  the  front  end. 

This  methodology  addressed  a  very  important  concern  identified  by  several 
stakeholders;  therefore  it  meets  the  system  configuration  portion  of  the  modifiability 
quality  attribute  identified  in  the  generic  architecture. 
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Scenario  #: 

2 

Scenario: 

The  system  must  automatically  execute  removal  of  advertised  billet  upon  its  expiration 

date. 

Attribute(s): 

Timeliness 

Environment: 

Normal  operating  conditions. 

Stimulus: 

Time  triggered  event.  Daily  the  system  will  perform  a  query  that  determines  which 

billets  are  about  to  expire,  which  have  expired  and  which  are  greater  than  two  weeks 

past  their  expiry  date. 

Response: 

The  system  will  respond  in  the  following  manner: 

1 .  It  will  notify  recruiters  and  employers  of  all  billets  that  are  within  two  weeks 

of  its  expiration  date. 

2.  A  follow-up  notice  is  transmitted  to  both  the  recruiters  and  employers  one 

week  from  the  expiration  date. 

3.  At  the  expiration  date  the  vacancy  is  locked  and  no  one  can  apply  for  it,  but  it 

will  remain  posted  on  the  site  for  an  additional  two  weeks  in  order  to  serve  as 

a  recruiting  tool.  Employers  are  notified  of  billets  that  remain  unfilled. 

4.  Two  weeks  after  the  expiration  date  the  vacancy  are  removed  from  the  active 

site  and  archived. 

Architectural 

A  daily  temporal  event  triggers  a  SQL  query  of  active  data  repository,  and  results  are 

decisions: 

transmitted  via  notification  process. 

Reasoning: 

Daily  querying  against  the  active  data  repository  ensures  that  only  viable,  active  billets 

are  displayed  for  applicants  conducting  searches.  It  also  minimizes  the  amount  of  false 

applications.  It  keeps  the  data  clean. 

Daily  querying  also  provides  recruiters  and  employers  with  notifications  to  ensure  that 

they  understand  the  time  constraints  associated  with  vacant  billets. 

This  provides  employers  an  opportunity  to  modify  the  billet  if  so  desired,  and  it  also 

provides  recruiters  with  information  that  will  allow  them  to  correctly  prioritize  their 

efforts. 

97 


Diagram: 

(verbal  description) 


Daily,  at  a  time  determined  by  the  system  manager,  the  system  will  query  the  active 
data  repository.  The  results  of  the  query  are  transmitted  to  the  BGW.  The  BGW  will 
then  pass  a  SOAP  message  to  the  appropriate  recipients.  The  recipients  systems  will 
then  post  the  announcement  in  the  ALERT  section,  as  well  as,  generate  an  instant 


message  or  email  to  notify  the  concerned  parties. 


Diagram: 


(pictorial  presentation) 


Analysis: 


This  event  ensures  that  the  data  being  presented  to  candidates  is  accurate  and  timely.  It 


will  also  assist  the  employers  by  providing  them  with  warnings.  These  warnings  will 


allow  the  employer  to  either  change  the  expiry  date  or  push  the  recruiters  to  fill  the 


billet  by  raising  its  priority.  Recruiters  are  provided  with  a  notification  in  order  to  keep 


them  focused  on  the  most  significant  events. 


This  event  does  generate  email,  which  is  not  desirable,  but  the  significance  of  the 
event  overrides  the  desire  to  minimize  spam  therefore  it  is  transmitted. 
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Scenario  #: 

3 

Scenario: 

The  system  must  automatically  populate  fields  in  RDOL  from  external  sources 

(Operational  Data  Storage  Enterprise  (ODSE),  Total  Force  Structure  Management 

System  (TFSMS))  wherever  possible. 

Attribute(s): 

Automation  (specifically  billet  management  in  this  scenario) 

Environment: 

Normal  operating  conditions. 

Stimulus: 

Temporal  or  physical  events  trigger  this  action.  Specifically: 

1.  The  system  will  query  billet  data  sources  weekly  to  ensure  that  the 

information  contained  in  the  active  billet  repository  is  up  to  date. 

2.  Any  major  manual  updates  to  the  Marine  Corps  billet  structure  or  manning 

structure  within  the  legacy  systems  (TFSMS)  will  trigger  this  event. 

Response: 

When  a  trigger  occurs  the  reserve  management  system  will  query  the  Marine  Corps 

legacy  systems.  The  results  of  the  query  are  used  to  update  the  active  data  repository 

that  the  Monster.com  site  pulls  data  from. 

Architectural 

1.  Applications  housed  in  the  middle  tier  will  provide  access  to  the  different 

decisions: 

data  repositories  housed  within  the  Marine  Corps  Enterprise  system.  This 

application  will  also  transform  the  data  retrieved  into  the  proper  format  that  is 

specified  by  this  system’s  business  rules. 

2.  The  system  will  then  compare  on-hand  Marines  (ODSE  data)  versus  the 

required  Marines  (TFSMS  data).  Any  disparities  between  on-hand  Marines 

(actual)  and  Table  of  Organization  billets  (ideal)  will  create  an  advertisement 

from  each  vacancy  that  exists  after  comparing  the  two  datasets. 

3.  Query  results  are  transmitted  via  FTPS  from  the  Reserve  Management 

System  to  the  Monster.com  system  to  ensure  the  safety  and  integrity  of  the 

data. 

Reasoning: 

This  automation  will  alleviate  much  of  the  work  that  is  currently  done  by  hand.  It  will 

also  ensure  that  the  billets  being  advertised  are  current. 
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Diagram: 

(verbal  description) 

When  a  trigger  event  occurs  the  system  will  query  the  legacy  systems.  The  results 

from  the  query  are  processed,  and  vacant  billets  are  identified.  These  results  are 

converted  into  a  SOAP  message  and  transmitted  via  the  BGW  to  the  Monster  system. 

These  active  data  repositories  are  updated,  and  the  new  job  vacancies  are  available  for 

consumption  by  reservists. 

Diagram: 

(pictorial  presentation) 

System  Generated  Soap  Msg  > —  _  ,  . ~~~'i  ( | 

Q,Jery  pterT'cwp"'^  ReSU"S  ll^jl  Duplay  Results  L 

^^^serve  Legacy  Reserve  .  .  n  .  Can 

Management  SVstems  Management  Monster.com  Act.eData 

System  System 

Analysis: 

The  ability  to  query  data  from  two  legacy  applications  is  a  significant  improvement 

from  the  previous  version  of  RDOL  and  is  the  key  to  alleviating  dirty  data  and  saving 

numerous  man  hours.  This  scenario  also  stresses  the  dependence  of  the  “Automation” 

quality  attribute  on  the  “Integration”  quality  attribute.  Because  if  the  system  cannot 

communicate  and  integrate  the  data  received  from  the  legacy  systems  the  automation 

of  the  system  will  fail.  This  also  makes  it  evident  that  the  Billet  Calculation  Module 

that  will  query  and  transform  information  from  the  legacy  systems  plays  a  significant 

role  in  this  process.  If  this  module  does  not  work  properly  the  automation  quality 

attribute  is  not  met,  therefore,  before  deployment  of  the  system,  this  module  must 

undergo  significant  testing  and  evaluation. 
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Scenario  #: 

4 

Scenario: 

The  system  must  allow  reservists  to  search  postings,  modify  resumes,  and  edit 

preferences. 

Attribute(s): 

Usability 

Environment: 

Normal  operating  conditions. 

Stimulus: 

1 .  A  reservist  queries  the  site  for  vacant  positions  of  interest. 

2.  A  reservist  chooses  to  view  or  modify  his  or  her  resume. 

3.  A  reservist  changes  their  notification  preferences  within  the  system. 

Response: 

1.  The  Monster.com  system  will  generate  a  query  against  the  active  data 

repository  housed  within  Monster’s  domain. 

2.  The  Monster.com  will  generate  a  query  against  the  Marine  Corps  data 

repositories.  The  results  of  the  query  will  auto-populate  a  member’s  resume. 

3.  The  reservist  will  make  changes  directly  to  a  “preference”  table  that  the 

system  uses  as  arguments  for  functions  of  the  system. 

Architectural 

Auto-populating  fields  make  it  easier  for  the  user  to  fill  out  resumes  while  eliminating 

decisions: 

the  chance  of  inputting  dirty  data,  and  it  also  ensures  that  the  reservists  are  updating 

their  personal  information. 

Reasoning: 

The  following  architectural  decisions  were  made  when  creating  this  application: 

Viewing  Vacant  Positions 

1 .  All  active  job  vacancies  are  housed  in  the  active  data  repository. 

2.  All  functionality  to  query  the  active  data  repository  are  contained  in  the 

Monster.com  system. 

Modifying  Resume 

1.  All  personal  information  fields  of  the  resume  will  populate  automatically  by 

the  information  contained  in  the  Marine  Corps  data  repositories 

(MCTFS/ODSE). 

2.  Every  transaction  is  logged  and  accounted  for  to  ensure  that  every  transaction 

is  processed  properly. 
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3.  All  personal  data  is  transmitted  via  HTTPS  or  FTPS  using  a  SSL.  Each  SOAP 
header  will  contain  a  ticket  that  will  uniquely  identify  and  verify  a  user  and 
his/her  privileges. 

4.  Only  certain  fields  are  modifiable  by  the  candidate.  If  a  candidate  identifies  a 
field  that  needs  correction,  but  is  not  modifiable,  the  user  is  directed  to  the 
resource  that  can  modify  it  (MOL). 

Notification  Preferences 

1.  Preferences  are  stored  in  a  table  in  the  active  data  warehouse. 

2.  Reservists  will  use  an  application  to  change  the  information  contained  within 
this  warehouse. 


3.  Business  rules  will  limit  a  Manager  can  change. 


Diagram  1: 


Once  a  reservist  is  logged  on  to  the  system  and  his/her  credentials  are  verified,  the 


(verbal  description) 


reservist  will  input  their  search  criteria  into  the  query  application.  The  Query 


Application  queries  the  active  data  repository  and  the  results  are  displayed  for  the 


reservist. 


Diagram  1: 

(pictorial  presentation) 


Query  Active  Data 

Application  Repository 


Diagram  2: 

(verbal  description) 


Once  a  reservist  is  logged  on  to  the  system  and  his/her  credentials  are  verified,  the 
reservist  requests  his  or  her  resume.  The  system  generates  a  query  which  is  transmitted 
via  the  BGW  to  the  Reserve  Management  System.  The  Reserve  Management  system 
queries  the  Marine  Corps  Enterprise  data  repositories  and  the  results  are  sent  back  to 
the  Monster  system.  The  Monster  system  processes  the  information  and  uses  it  to 
populate  the  resume  requested  by  the  reservist. 
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Diagram  3: 


Once  a  reservist  is  logged  on  to  the  system  and  his/her  credentials  are  verified,  the 


(verbal  description) 


reservist  will  input  his/her  search  criteria  into  the  query  application.  The  Preference 


Application  will  provide  a  structure  environment  in  which  the  reservist  can  directly 


update  their  preference  information  in  the  active  data  repository. 


Diagram  3: 

(pictorial  presentation) 


Preference 

Application 


Active  Data 
Repository 


Message 


Change  Confirmation 
Message 


Analysis: 


The  system  responds  well  to  the  scenarios.  The  following  were  some  vulnerabilities 
that  were  noted  during  the  analysis:  First,  the  preference  application  worked  directly 
with  table  data  which,  if  not  done  correctly,  could  negatively  affect  the  normalization 
and  the  integrity  of  data  being  stored  in  the  repository.  Second,  the  auto-population  of 
a  resume  will  significantly  limit  which  fields  the  reservist  can  update.  Specifically  it 
will  limit  them  to  updating  recall  information  and  address  information.  The  Marine 
Corps  will  not  allow  a  reservist  to  modify  or  update  any  professional  or  other  personal 
attribute  without  coordinating  it  with  the  Marine  Corps  personnel  office.  This  will 
significantly  slow  this  process  down,  and  could  lead  to  resumes  being  submitted  with 
incorrect  data  to  circumvent  this  tedious  and  slow  process. 


F.  RISK  MANAGEMENT  STRATEGY 

As  with  any  architecture,  there  are  potential  flaws  associated  with  our  proposed 
architecture.  Our  goal  for  this  section  is  to  minimize  the  risk  that  these  “flaws”  expose  to 
our  stakeholders.  In  that  light,  we  examined  our  proposal  from  the  top  down,  and 
identified  any  weak  areas  or  potential  threats  to  the  proposed  architecture.  We  then 
thoroughly  analyzed  each  of  these  weakness,  and  attempted  to  determine  the  probability, 
analytically  not  qualitatively,  that  the  event  would  occur,  as  well  as,  we  attempted  to 
prognosticate  the  scope  of  the  damage  to  the  system  if  the  event  occurred.  We  then  used 
the  results  of  the  analysis  to  prioritize  the  different  risks  to  the  proposed  architecture. 
Each  of  these  risks  are  presented  below  in  sequential  order. 


103 


1.  Single  Point  of  Failure 

The  BGW  is  a  single  point  of  failure,  and  represents  the  biggest  threat  to  the 
system.  The  Internet  has  no  business  hours  and  the  numerous  users  of  RDOL  are  spread 
throughout  the  globe  in  many  different  time  zones.  With  the  BGW  being  a  single  point 
of  failure,  the  cost  of  losing  this  middleware  is  compared  to  the  requirements  identified  in 
the  QA  “availability”  as  defined  by  the  stakeholders.  As  Gorton  pointed  out, 
“Replicating  components  is  a  tried  and  tested  strategy  for  high  availability.  When  a 
replicated  component  fails,  the  application  can  continue  executing  using  replicas  that  are 
still  functioning.  This  may  lead  to  degraded  perfonnance  while  the  failed  component  is 
down,  but  availability  is  not  compromised  [26].” 

Coupled  with  availability  is  the  issue  of  recoverability.  Recoverability  is  defined 
as  the  capability  to  reestablish  the  systems  required  performance  levels  and  restore  data 
that  was  interrupted  during  the  outage/failure.  In  the  case  of  RDOL,  during  a  system 
outage,  the  only  billets  that  could  not  be  automatically  recreated  very  quickly  would  be 
the  Individual  Augment  (IA)/ Active  Duty  Operational  Support  (ADOS)  billets  that  were 
manually  entered.  A  broadcast  message  could  be  sent  following  the  outage  notifying 
users  that  there  was  an  outage  and  to  validate  all  recent  manually  inputted  billets. 
Component  replication  does  ensure  as  close  to  100%  availability  but  comes  at  a 
significant  cost.  This  cost  would  have  to  be  weighed  against  a  less  complicated  solution 
such  as  daily  off-site  backups  of  the  active  billet  repository. 

Finally,  mitigating  the  risk  of  the  BGW  acting  as  a  single  point  of  failure  boils 
down  to  the  amount  of  cost  you  are  willing  to  incur.  At  one  end  of  the  spectrum  you 
could  have  multiple,  redundant,  load  balanced  applications  at  separate  sites  that  will 
process  and  transmit  data  in  parallel  (this  can  create  its  own  set  of  problems  with 
inconsistencies/  transactions).  On  the  other  end  of  the  spectrum,  you  have  the  minimum 
of  nightly  off-site  backups.  It  comes  down  to  how  much  you  are  willing  to  spend  to  get 
the  availability/recoverability  that  is  desired.  No  solution  is  perfect;  it  comes  down  to 
risk  versus  gain.  In  this  case,  due  to  the  nature  of  the  proposed  system  we  recommend 
that  you  minimize  the  costs  of  the  system  by  conducting  nightly  backups.  Monster.com 

has  numerous  mirror  sites  to  protect  the  BGW,  so  the  cost  of  the  redundant  systems  need 
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not  be  incurred  by  the  government,  and  the  backing  up  the  daily  transactions  would 
provide  additional  protection  to  the  risk  posed  by  using  star  topology. 

2.  Unauthorized  Access 

Due  to  the  large  number  and  dispersed  access  points  to  the  system,  unauthorized 
access  to  the  system  poses  a  significant  threat  to  its  users  and  the  Marine  Corps.  To 
mitigate  this  risk  an  active  role  management  program  is  implemented.  The  primary 
responsibility  of  the  management  of  this  program  is  the  Career  Management  Team 
(CMT)  system  administrators.  Users  of  the  system  should  only  have  access  to  areas  in 
which  they  have  been  granted  privileges.  If  a  user  goes  beyond  the  boundaries  established 
by  the  system  administrator,  his  or  her  account  is  locked  out  and  system  administrators 
will  be  notified  of  the  breach.  More  specifically,  in  order  to  mitigate  the  risk  between 
usability  and  security,  access  to  resumes  is  granted  only  to  employers  and  managers.  The 
employers  and  manager  website  access  will  utilize  a  Common  Access  Card  (CAC)  with 
Public  Key  Infrastructure  (PKI)  to  ensure  those  users  accessing  personal  data  are  trusted. 
In  order  to  keep  usability  high  for  our  most  important  end  users  (the  reservists),  they  will 
be  able  to  login,  browse  and  apply  for  billets,  manager  their  resumes  and  view  their 
personal  information  using  only  a  strong  password.  The  only  personnel  that  would  need 
to  review  resumes  containing  personal  data  are  employers.  All  employers  using  this 
system  will  have  access  to  CAC  readers,  and  must  have  completed  a  DD  2875  (System 
Authorization  Access  Request)  which  signifies  that  the  user  has  attended  the  required 
Infonnation  Assurance  training.  By  PKI  enabling  the  manager  and  employer  portion  of 
the  system,  it  will  be  significantly  more  difficult  to  breach  personal  data. 

Additionally,  specific  ranges  are  added  to  each  employers  profile,  for  example,  if 
the  employer  manages  a  Motor  Transport  IMA  detachment,  then  they  do  not  need  to  see 
the  resume  of  a  Gunnery  Sergeant  with  an  MOS  of  3381  (Cook).  When  establishing  his 
or  her  credentials  the  system  could  be  designed  to  force  the  CMT  system  administrators 
to  click  checkboxes  for  each  required  MOS  necessary  for  that  specific  billet  manager. 
The  Master  access  list  will  be  maintained  by  Monster  and  updated  by  the  CMT  system 
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managers.  This  will  ensure  that  the  authorization  tickets  contained  in  the  SOAP  headers 
are  able  to  identify  a  unique  member  and  his  or  her  access  privileges. 

3.  Security  Concerns 

There  is  a  significant  security  concern  when  government  and  commercial 
products  are  coupled.  This  system  uses  the  hub  and  spoke  architecture  which  decouples 
the  systems  and  keeps  them  isolated  from  each  other.  Their  only  communication  is 
through  the  intennediary  hardware,  which  limits  the  threat.  The  system  will  use 
Customer  Access  Tickets  (CAT),  which  are  encrypted  strings  that  include  authentication 
information  for  the  server  sending  the  request  (username/password  and  IP)  to  uniquely 
identify  agencies,  as  well  as,  the  users.  This  system  guarantees  the  identity  of  the  both 
entities. 

4.  Data  Entry  Errors 

Due  to  volume  of  personnel  entering  data  into  the  system,  there  is  a  significant 
risk  of  information  inadvertently  being  modified  or  entered  incorrectly.  For  example,  an 
advertisement  may  be  deleted  accidentally  or  an  application  inputted  might  contain  such 
mistakes  as  spelling  or  punctuation  errors.  To  ensure  that  information  is  not  changed  or 
modified  inadvertently  by  a  rogue  user,  all  infonnation  entered  into  the  system  will  be 
tied  to  the  system  by  the  user’s  unique  identification.  Only  the  author  or  a  system 
administrator  can  change  the  document  after  it  has  been  posted.  Furthermore,  all 
advertisements  will  be  tied  to  the  Billet  Identification  Code  (BIC).  A  BIC  is  an  11 
character  alpha-numeric  text  block  that  uniquely  identifies  a  billet  within  a  specific 
reporting  unit  code  table  of  organization.  Employers  are  limited  to  posting 
advertisements  for  vacant  billets  for  jobs  that  correspond  to  specific  BICs  assigned  to 
their  RUC;  this  will  prevent  any  type  of  cross  posting  between  employers  and  keep  them 
from  deleting  one  another’s  advertisements.  In  the  case  of  the  IA/ADOS  billets  which  do 
not  have  a  BIC,  all  the  input  form  data  will  be  auto  populated  by  a  query  of  the 
MCTFS/TFSMS  legacy  systems.  This  will  prevent  dirty  data  from  being  entered  into  the 
system. 
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In  order  to  ensure  that  all  data  that  is  used  to  auto  populate  applications  used  by 
the  employers  and  the  applicants,  information  will  be  drawn  from  the  Marine  Corps  fixed 
data  repositories  (MCTFS/TFSMS).  For  example,  in  the  case  of  the  reservist’s  resume, 
all  infonnation  will  be  drawn  directly  from  MCTFS  with  the  exception  of  a  free-form  text 
block  in  which  a  reservist  can  input  any  additional  infonnation  that  is  not  MCTFS 
reportable.  This  block  could  include  information  relating  to  their  civilian 
employment/school  schedule. 

5.  Potential  Hidden  Costs 

There  are  potential  hidden  costs  due  to  the  system  being  a  hybrid  solution.  To 
mitigate  this  risk  all  costs  will  be  defined,  fixed  and  structured  into  the  contract  at  the 
inception  of  the  deal  the  following  are  some  additional  cost  reduction  strategies  that  can 
be  employed: 

•  A  significant  portion  of  the  costs  will  be  incurred  at  inception  due  to  the  nature  of 
the  solution  being  utilized,  i.e.  COTS  technologies  integrated  with  the  PLA.  Once 
the  system  is  up  and  running,  maintenance  costs  will  be  minimal,  but  the  contract 
will  be  specific  that  Monster.com  will  be  responsible  for  the  life  cycle 
maintenance  of  their  systems. 

•  Costs  can  also  be  controlled  by  prioritizing  the  wish  list  generated  by  the 
stakeholders  of  the  system.  The  prioritization  will  be  done  by  the  key  stakeholders 
to  ensure  that  they  agree  to  the  ranking  of  the  different  attributes.  “Wishes”  with  a 
low  priority  will  only  be  funded  if  excess  funds  are  available. 

•  Interview  other  government  agencies  that  are  currently  utilizing  a  Monster 
Government  Solution  (MGS).  Analyze  their  contract  (most  government  agencies 
shouldn’t  treat  these  contracts  as  intellectual  property),  speak  with  their  IT 
procurement  department;  find  out  where  money  could  have  been  saved.  Look  for 
costs  that  can  be  minimized  or  avoided.  These  vendors  often  tack  on  numerous 
additional  charges  that  may  seem  important  or  necessary,  but  ask  other 
government  monster  users  how  important  or  necessary  they  really  are.  In  the  case 

the  Marine  Corps  Reserve  system,  will  their  system  really  require  that  a  Monster 
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contractor  be  on  call  that  can  troubleshoot  the  system  in  two  minutes  or  less? 
This  is  not  worth  it  for  the  Marine  Corps  Reserve,  and  money  can  be  saved  by 
eliminating  this  requirement. 

•  When  interviewing  other  users  of  the  MGS  users  detennine  who  did  the 
integration  of  legacy  applications  with  the  new  system.  Determine  what  was  their 
Capability  Mature  Model  (CMM)  level  is,  and  determine  if  the  project  manager 
PMI  certified.  The  thought  behind  this  it  to  use  the  lowest  level  of  CMM  possible 
to  keep  costs  down. 

•  Don’t  fall  for  bells  and  whistles  you  don’t  need.  For  example,  when  buying  car  it 
is  easy  to  buy  unnecessary  upgrades  or  accessories.  The  same  is  true  when 
negotiating  what  services  will  be  provided  by  a  COTS  vendor.  To  minimize  this 
risk  the  architect  must  clearly  define  what  is  actually  required.  By  doing  this 
numerous  extra  expenses  can  be  eliminated. 

•  Build  a  cost  matrix  with  following  arguments  inputted  into  a  cost  function: 

o  Identifying  criteria  -  detailed  cost  list  of  the  different  services  that  are 
available  for  purchase. 

o  Rating  of  each  criterion  -  a  weighting  mechanism  to  adjust  the  cost  of  the 
different  services. 

From  this  matrix  a  weighted  total  score  will  be  generated  for  each  alternative. 
Obviously  more  arguments  can  be  added  to  the  function,  but  the  point  is  you  can 
use  this  tool  to  determine  if  the  costs  being  charged  are  agreeable. 

•  If  Monster  utilizes  an  enterprise  license  agreement  (ELA),  ensure  that  detailed  figures 
are  obtained  in  regards  to  how  costs  are  calculated.  For  example,  if  Monster  charges 
per  transactions  through  the  BGW,  or  concurrent  users  that  must  be  known  up  front. 

These  five  risks  obviously  are  not  the  only  risks  that  the  system  will  exposed  to, 
but  they  do  represent  the  most  significant  and  viable  threats  to  the  proposed  system.  It  is 
important  that,  at  minimum,  that  these  risks  are  aggressively  managed  and  mitigated. 
Other  risks  that  were  identified  but  not  addressed  in  this  document  include: 
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organizational  buy-in,  residual  risks  associated  with  the  relationship  between  the  COTS 
systems  and  government  system  and  capacity  concerns.  Obviously,  these  are  not  all 
inclusive,  but  they  make  it  apparent  that  before  an  actual  system  is  selected  another 
thorough  examination  of  the  risks  needs  to  be  conducted. 
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VII.  SUMMARY,  CONCLUSIONS  AND  FUTURE  RESEARCH 


The  primary  objective  of  this  thesis  is  to  provide  the  Marine  Corps  with  a 
thorough  bottom  up  System  Analysis  of  the  next  generation  billet  advertisement  system 
that  will  replace  RDOL.  The  analysis  includes  a  detailed  systems  analysis,  a  generic 
architecture,  logical  data  models,  process  models  and  a  system  model  which  provides  the 
Marine  Corps  with  a  blueprint  of  the  requirements  for  the  next  generation  system  of 
record.  The  secondary  objective  of  this  thesis  was  to  analyze  current  system  architectures 
that  advertise  and  fill  job  vacancies  within  the  Department  of  Defense  (DoD),  as  well  as 
commercial-off-the-shelf  (COTS)  products  in  order  to  identify  what  architecture  should 
be  leveraged  by  the  Marine  Corps  during  its  next  generation  system.  The  combination  of 
these  two  objectives  will  be  coalesced  together  to  form  a  roadmap  for  the  Marine  Corps 
to  follow  for  the  design  of  its  next  generation  system. 

This  chapter  is  organized  as  follows:  First  a  summary  of  the  results  uncovered 
during  literature  review,  examination  of  similar  systems,  and  the  system  analysis  and 
architectural  design  of  the  proposed  system  is  presented.  Second,  conclusions  drawn  from 
this  thesis  research  are  presented  and  discussed.  The  third  section  provides  direction  for 
future  research,  focusing  on  improvements  and  refinements  that  will  ultimately  provide 
the  Marine  Corps  with  an  optimal  and  adaptive  system  to  advertise  vacant  reserve  billets. 

A.  SUMMARY  OF  FINDINGS 

1.  Literature  review 

We  garnered  valuable  information  from  the  analysis  the  Air  Force’s  ViPS,  the 
Navy’s  JOAPPLY,  and  Monster.com  subsidiary  USAJOBs.  Specifically,  we  were  able  to 
capture  industry  best  practices,  and  identify  significant  weaknesses  and  shortcomings  that 
should  be  avoided  in  the  design  of  the  new  system.  These  lessons  learned  were  included 
in  the  logical  design  of  the  Marine  Corps’  next  generation  system.  Some  of  the  more 
pertinent  learning  points  collected  from  this  literature  review  were:  (1)  The  Air  Force’s 
ViPS  system  was  highly  successful  because  of  a  thorough  requirements  analysis 
performed  by  the  Air  Force  and  the  contractor  SAIC  during  the  design  and  development 
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of  the  system.  The  Marine  Corps  must  build  upon  this  idea  and  ensure  that  the 
stakeholder’s  requirements  are  genuinely  understood  before  building  their  next 
generation  system.  Beyond  a  detailed  requirements  analysis,  the  ViPS  graphical  user 
interface  was  intuitive  and  the  functionality  was  sound,  which  makes  it  a  tool  that  its 
stakeholders  actually  use.  This  currently  isn’t  the  case  for  RDOL,  and  the  next  system 
fielded  by  the  Marine  Corps  needs  to  address  this  deficiency.  (2)  The  Navy’s  JOAPPLY 
system  provided  a  good  example  of  how  a  user  can  use  a  web  enable  billet  advertisement 
system  to  manage  their  career.  Specifically,  JOAPPLY  provided  a  reservist  with  dynamic 
and  robust  set  of  career  management  tools  that  allowed  him/her  to  be  an  active  participant 
in  the  detailing  process.  Unfortunately,  the  system  as  a  whole  was  built  haphazardly  and 
lacked  other  significant  functionality,  which,  again,  emphasizes  the  importance  of  system 
requirements  analysis  and  documentation.  The  desirable  career  management  attributes 
were  incorporated  into  the  quality  attributes  for  the  proposal  of  the  next  Marine  Corps 
system.  (3)  The  USAJOBs  provided  the  Marine  Corps  with  a  pertinent  and  real  example 
of  how  the  government  can  harness  the  synergy  and  prowess  of  mature  turnkey  COTS 
product.  This  product  also  provided  the  blueprint  of  an  architecture  that  is  viable  for  a 
web  enable  billet  advertisement  system. 

2.  Results  of  System  Analysis 

The  primary  reason  the  current  system  failed  is  due  to  the  lack  of  a 
comprehensive  requirements  analysis  at  the  inception  of  the  project.  During  the 
requirements  analysis  for  RDOL,  the  majority  of  pertinent  stakeholders  were  excluded 
from  the  process,  which  resulted  in  a  fragmented  and  incomplete  system  specification. 
Therefore,  the  emphasis  of  this  thesis  has  been  on  specifying  all  of  the  stakeholder’s 
requirements  for  the  next  generation  Marine  Corps  billet  advertisement  system.  This  was 
accomplished  by  identifying  the  stakeholder’s  requirements  for  an  ideal  billet 
advertisement  system  through  interviews  and  working  groups.  The  results  were  broken 
into  two  functional  areas:  Data  Business  Requirements  and  Process  Business 
Requirements. 

The  Data  Business  Requirements  section  focused  on  the  data  and  the  data 

structure  required  for  the  next  system  to  be  successful.  This  analysis  revealed  four  main 
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top-level  entities.  These  are  candidates,  employers,  managers  and  recruiters.  The 
attributes  and  the  relationships  between  these  entities  were  expanded  upon  using  an 
Entity  Relationship  Diagram.  Ultimately,  this  process  captured  the  basic  data  structure 
required  for  this  system  to  be  successful,  but  these  only  represent  a  high-level  view  of  the 
data  structure  for  the  system.  The  Marine  Corps  needs  to  refine  these  data  requirements 
before  they  complete  the  acquisition  process. 

The  Process  Business  Requirements  defined  the  scope  of  the  system,  as  well  as, 
the  functional  requirements  of  the  system.  The  scope  of  the  system  is  presented  in  a 
Context  Data  Flow  Diagram.  This  diagram  clearly  defines  the  external  interactions  and 
boundaries  of  the  proposed  system.  This  process  model  was  further  refined  by  using  a 
Functional  Decomposition  Diagram,  which  expands  upon  the  system  by  breaking  it  down 
into  its  core  functional  constituents.  These  are  the  candidates,  employers,  managers  and 
recruiters.  These  four  sub-groups  are  further  broken  down  into  their  core  functional 
requirements  or  each  sub-group  which  are  expanded  upon  and  defined  by  use  cases. 

3.  Results  of  Architecture  Analysis 

The  results  of  the  requirements  analysis  yielded  enough  information  to  identify 
specific  components  that  can  be  used  by  the  system,  but  this  analysis  did  not  address  the 
framework,  or  architecture,  that  needs  to  be  implemented  to  support  these  components. 
To  address  this  disparity,  the  Architecture  Tradeoff  Analysis  Method  (ATAM)  was  used 
to  identify  an  appropriate  architecture  to  meet  the  needs  of  the  proposed  system.  The 
ATAM  is  a  nine-step  methodology  for  evaluating  architecture  designs  that  uses 
stakeholder  defined  quality  attributes  as  a  metrics  to  gauge  whether  or  not  the  proposed 
architecture  will  meet  its  defined  objectives. 

The  ATAM  process,  along  with  the  results  of  the  systems  analysis  and  literature 
review,  identified  the  hub  and  spoke  topology  as  the  best  solution  for  this  project.  It 
afforded  the  Marine  Corps  with  the  most  robust  and  versatile  solution  for  its  problem  set. 
Using  scenarios  as  a  medium,  quality  attributes  were  used  to  measure  the  effectiveness  of 
the  proposed  architecture.  In  the  instances  that  were  substantiated,  the  proposed 
architecture  met  all  of  the  requirements  defined  by  the  quality  attributes,  and  the 
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proposed  architecture  appears  to  be  viable  and  a  good  selection.  But  further  analysis  is 
needed  as  only  a  small  subset  of  the  quality  attributes  have  been  used  to  stress  the 
proposed  architecture,  and  a  more  thorough  testing  has  to  be  completed  before  the  Marine 
Corps  can  unequivocally  call  the  proposed  architecture  the  right  one. 

The  ATAM  also  provided  additional  findings  that  were  useful  to  the  project. 
Specifically,  it  helped  further  define  and  clarify  stakeholder  requirements;  it  identified 
some  potential  risks  early  in  the  life-cycle  of  the  system,  and  an  increased  communication 
among  stakeholders.  The  analysis  also  made  it  apparent  that  the  complexity  inherent  in 
designing  a  real  world  web  application  for  numerous  stakeholders  that  architecture 
tradeoff  analysis  is  rarefy  a  straightforward  activity.  Each  step  of  the  ATAM  answered 
some  design  questions,  but  it  also  brought  some  issues  to  light  that  we  had  neglected  to 
focus  on. 

B.  CONCLUSIONS 

The  problems  and  issues  surrounding  RDOL  can  be  eliminated.  It  will,  however, 
take  time,  money,  and  the  combined  effort  on  the  part  of  many  people.  In  the  midst  of 
the  long  war,  it  is  clearly  evident  that  the  reserve  is  an  integral  part  of  the  Marine  Corps 
total  force.  This  integration  hinges  on  the  recognition  that  the  ability  for  our  reservists  to 
be  able  to  easily  search  and  identify  available  opportunities  is  of  the  utmost  importance. 
Additionally,  it  is  equivocally  important  for  employers  to  have  those  same  abilities  to 
seek  out  potential  reservists  to  fill  various  types  of  reserve  billets.  The  current  manpower 
struggles  the  Marine  Corps  faces  requires  that  we  do  our  best  to  put  our  reserve  Marines 
in  the  right  billets  at  the  right  time.  The  proposed  architecture  and  requirements  analysis 
presented  in  this  thesis  will  provide  a  solid  foundation  for  the  next  generation  system, 
but,  as  noted  earlier,  more  work  has  to  be  done  to  ensure  that  the  Marine  Corps  does  not 
build  a  system  that  does  not  fully  meet  its  requirements. 
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C.  FUTURE  RESEARCH 

While  this  thesis  focused  on  understanding  the  requirements  and  design  of  the 
new  system,  there  is  a  considerable  amount  of  work  that  needs  to  be  accomplished.  This 
work  includes  the  completion  of  the  remaining  steps  of  the  FAST  and  ATAM 
methodologies  which  include: 

Decision  Analysis:  During  this  phase  candidate  solutions  are  identified, 
feasibility  analysis  is  conducted,  and  a  candidate  system  is  recommended  that  best  fits  the 
needs  of  the  Marine  Corps.  Feasibility  analysis  includes  technical,  operational,  economic, 
schedule  and  risk  feasibility.  At  the  end  of  this  phase,  a  system  proposal  is  generated 
which  will  include  conclusions  and  recommendations. 

Physical  Design:  This  phase  commences  once  a  candidate  solution  has  been 
selected,  and  has  proven  to  be  feasible.  It  takes  the  logical  model  and  converts  it  into  an 
operating  physical  model.  At  this  point  a  determination  on  what  technologies  best 
provide  a  solution  to  the  problem  domain  will  be  decided  upon,  such  as,  the  technical 
requirements  of  the  database  and  any  software  or  middleware  requirements.  Upon 
completion  of  this  phase  an  operating  prototype  is  built. 

Construction  and  testing:  Once  the  physical  model  is  built,  developers  can  begin 
constructing  and  testing  components  of  the  system.  During  this  phase  developers  begin 
beta  testing  the  prototype  built  in  the  Physical  Design  phase.  Results  from  the  beta-testing 
are  delivered  to  major  stakeholders. 

Installation  and  delivery:  Once  construction  and  testing  are  complete,  the 
system  can  be  delivered  and  installed.  This  step  would  be  addressed  by  Headquarters 
Marine  Corps. 

Another  element  not  addressed  by  this  thesis  work  is  the  important  element  of 
cost.  Specifically,  a  detailed  cost  analysis  of  proposed  COTS  hybrid  solutions  needs  to  be 
completed. 


115 


Finally  a  feasibility  study  focused  on  the  viability  of  porting  the  Air  Force  ViPS 
application  and  modifying  it  to  become  a  Marine  Corps  system  of  record.  Our 
discussions  with  the  Air  Force  revealed  that  they  own  the  source  code  and  all  the 
necessary  documentation.  Although  our  personnel  systems  are  different,  ViPS  currently 
meets  many  of  the  requirements  and  quality  attributes  documented  in  this  thesis  work. 

In  conclusion,  we  strongly  believe  the  results  and  recommendations  of  this  thesis 
provide  the  Marine  Corps  with  a  solid  foundation  for  developing  the  next  generation 
Marine  Corps  Reserve  Billet  Advertisement  System.  In  addition,  the  thesis  provides  an 
archetype  that  can  be  leveraged  by  the  Marine  Corps  in  building  other  future  systems. 
This  will  not  only  result  in  money  savings,  but  will  ultimately  result  in  better  and  more 
robust  future  Marine  Corps  application  systems.  At  a  minimum,  both  of  these  results  and 
recommendations  ensure  that  the  Marine  Corps  will  produce  a  much  superior  Billet 
Advertisement  System  than  the  existing  one. 
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APPENDIX  A.  USE  CASE  GLOSSARY 


CANDIDATE  USE  CASES 

Id 

Use-Case  Name 

Use-Case  Description 

Participating  Actors  and  Roles 

1 

Contact  employer  for 
additional  information 

This  use  case  describes  how  a 
candidate  can  submit 
information  to  an  employer  to 
gain  additional  details  about  an 
advertisement. 

Candidate  (Primary  Actor) 

Employer  (System  Actor) 

2 

Create  Application 

This  Use  Case  describes  how  a 
Candidate  applies  for  an 
advertised  billet.  (Member  may 
apply  for  multiple  positions.) 

Candidate  (Primary  Actor) 

Employer  (Primary  Actor) 

3 

Review  Application 

This  Use  Case  describes  how  a 
Candidate  reviews  all  the  billets 
they  have  applied  for.  (No 
historical  data  will  be 
displayed.) 

Candidate  (Primary  Actor) 

4 

Update  Application 

This  Use  Case  describes  how  a 
Candidate  updates  a  current 
application  that  has  already 
been  submitted.  (Application 
can  be  updated  as  long  as  it  has 
not  been  approved  by  an 
Employer.) 

Candidate  (Primary  Actor) 

Employer  (Primary  Actor) 

5 

Delete  Application 

This  Use  Case  describes  how  a 
Candidate  deletes  an  application 
that  has  been  previously 
submitted. 

Candidate  (Primary  Actor) 

Employer  (Primary  Actor) 

6 

Create  Billet  Lead 
Subscription 

This  Use  Case  describes  how  a 
Candidate  can  create  a 
subscription  to  receive  updates 
(email  or  notification  on  portal) 
if  new  billets  that  fit  his  or  her 
criteria  (geo  loc,  dates)  have 
been  posted,  updated  or  deleted. 

Candidate  (Primary  Actor) 

Employer  (External  Receiver) 
Recruiter  (External  Receiver) 

7 

Review  Billet  Lead 
Subscription 

This  Use  Case  describes  how  a 
Candidate  can  review  their 
subscriptions  without  making 
any  modifications  to  them. 

Candidate  (Primary  Actor) 

8 

Update  Billet  Lead 
Subscription 

This  Use  Case  describes  how  a 
Candidate  can  modify  their 
current  subscriptions. 

Candidate  (Primary  Actor) 

Employer  (External  Receiver) 
Recruiter  (External  Receiver) 

9 

Delete  Billet  Lead 
Subscription 

This  Use  Case  describes  how  a 
Candidate  can  delete  any  of 
their  current  subscriptions. 

Candidate  (Primary  Actor) 

Employer  (External  Receiver) 
Recruiter  (External  Receiver) 

10 

Create  personal  web 
portal  content 

This  use  case  describes  how  a 
candidate  can  create  a 
personalized  web  portal  upon 
initial  login. 

Candidate  (Primary  Actor) 
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Id 

Use-Case  Name 

Use-Case  Description 

Participating  Actors  and  Roles 

11 

Review  personal  web 
portal  content 

This  use  case  describes  how  a 
candidate  can  review  the 
customizable  information 
contained  within  their  personal 
web  portal  (e.g.  RSS  feeds, 
content) 

Candidate  (Primary  Actor) 

12 

Update  personal  web 
portal  content 

This  use  case  describes  how  a 
candidate  can  update  the 
customizable  information 
contained  within  their  personal 
web  portal  (e.g.  RSS  feeds, 
content) 

Candidate  (Primary  Actor) 

13 

Delete  personal  web 
portal  content 

This  use  case  describes  how  a 
candidate  can  delete  the 
customizable  information 
contained  within  their  personal 
web  portal  (e.g.  RSS  feeds, 
content) 

Candidate  (Primary  Actor) 

14 

Use  External  Marine 
Corps  Services 

This  Use  Case  describes  how  a 
Candidate  can  use  external  links 
to  manage  their  career. 

Candidate  (Primary  Actor) 

15 

Review  Application 
History 

This  use  case  describes  how  a 
candidate  can  view  the  current 
details  of  all  active  and  prior 
billet  applications. 

Candidate  (Primary  Actor) 

16 

Participate  in 
community  events 

This  Use  Case  describes  how  a 
Candidate  can  use  the 
community  tools  available  in 
the  RBAS  system. 

Candidate  (Primary  Actor) 

Employer  (External  Receiver) 
Recruiter  (External  Receiver) 

17 

Search  Available 
Advertisements 

This  Use  Case  describes  how  a 
Candidate  can  search  for  jobs 
posted  by  Employers  that  match 
their  search  criteria. 

Candidate  (Primary  Actor) 

Employer  (Primary  Actor) 

18 

View  applicant  pool  for 
an  active  advertisement 

This  use  case  describes  how  a 
candidate  can  view  the  current 
details  of  an  active 
advertisement  with  respect  to 
other  candidates  that  have 
applied  for  a  billet. 

Candidate  (Primary  Actor) 

19 

Create  Reserve 
Qualification  Summary 

This  use  case  describes  how  a 
candidate  can  create  an 
electronic  Reserve  Qualification 
Summary  (RQS). 

Candidate  (Primary  Actor) 

Employer  (External  Receiver) 
Recruiter  (External  Receiver) 

20 

Review  Reserve 
Qualification  Summary 

This  use  case  describes  how  a 
candidate  can  review  their 
electronic  Reserve  Qualification 
Summary  (RQS). 

Candidate  (Primary  Actor) 

21 

Update  Reserve 
Qualification  Summary 

This  use  case  describes  how  a 
candidate  can  update  their 
electronic  Reserve  Qualification 
Summary  (RQS). 

Candidate  (Primary  Actor) 

Employer  (External  Receiver) 
Recruiter  (External  Receiver) 
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Id 

Use-Case  Name 

Use-Case  Description 

Participating  Actors  and  Roles 

22 

Delete  Reserve 
Qualification  Summary 

This  use  case  describes  how  a 
candidate  can  delete  their 
electronic  Reserve  Qualification 
Summary  (RQS). 

Candidate  (Primary  Actor) 

Employer  (External  Receiver) 
Recruiter  (External  Receiver) 

23 

Manage  Billet  Leads 

This  Use  Case  describes  how  a 
Candidate  can  manage  all  leads 
that  have  been  generated  for 
advertisements  that  are  included 
in  their  subscriptions. 

Candidate  (Primary  Actor) 

Employer  (System  Actor) 

RECRUITER  USE  CASES 

1 

Search  all  available 
billets 

This  Use  Case  describes  how  a 
recruiter  can  search  for  billets 
that  match  their  search  criteria 
(MOS,  GeoLoc,  Dates). 

Recruiter  (Primary  Actor) 

Employer  (External  Server) 

2 

Search  all  available 
candidates. 

This  Use  Case  describes  how  a 
Recruiter  can  search  all 
available  candidates  by  specific 
criteria  (MOS,  rank,  geo  loc, 
dates). 

Recruiter  (Primary  Actor) 

3 

Manage  Candidate 

Leads 

This  Use  Case  describes  how  a 
Recruiter  can  manage  all  leads 
that  have  been  generated  for 
billets  that  are  included  in  their 
district. 

Recruiter  (Primary  Actor) 

Candidate  (External  Server) 

4 

View  Adhoc  Report 

This  Use  Case  describes  how  a 
Recruiter  generates  and  views 
an  adhoc  report. 

Recruiter  (Primary  Actor) 

5 

View  Vacant  Billet 

Report 

This  Use  Case  describes  how  a 
Recruiter  views  a  report 
containing  ALL  vacant  billets 
with  or  without  the  use  of  a 
filter. 

Recruiter  (Primary  Actor) 

6 

Create  Personal  Web 
Portal  Content 

This  use  case  describes  how  a 
Recruiter  can  create  a 
personalized  web  portal  upon 
initial  login. 

Recruiter  (Primary  Actor) 

Manager  (External  Actor) 

7 

Review  Personal  Web 
Portal  Content 

This  use  case  describes  how  a 
Recruiter  can  review  the 
customizable  information 
contained  within  their  personal 
web  portal  (e.g.  RSS  feeds, 
content) 

Recruiter  (Primary  Actor) 

8 

Update  Personal  Web 
Portal  Content 

This  use  case  describes  how  a 
Recruiter  can  update  the 
customizable  information 
contained  within  their  personal 
web  portal  (e.g.  RSS  feeds, 
content) 

Recruiter  (Primary  Actor) 

9 

Delete  Personal  Web 
Portal  Content 

This  use  case  describes  how  a 
Recruiter  can  delete  the 
customizable  information 
contained  within  their  personal 
web  portal  (e.g.  RSS  feeds) 

Recruiter  (Primary  Actor) 
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Id 

Use-Case  Name 

Use-Case  Description 

Participating  Actors  and  Roles 

10 

Create  Candidate  Lead 
Subscription 

This  Use  Case  describes  how  a 
Recruiter  can  create  a 
subscription  to  receive  updates 
(email  or  notification  on  portal) 
if  new  candidates  that  fit  his  or 
her  criteria  (geo  loc,  dates, 

MOS)  have  been  posted, 
updated  or  deleted. 

Recruiter  (Primary  Actor) 

Candidate  (External  Server) 

11 

Review  Candidate  Lead 
Subscription 

This  Use  Case  describes  how  a 
Recruiter  can  review  their 
subscriptions  without  making 
any  modifications  to  them. 

Recruiter  (Primary  Actor) 

12 

Update  Candidate  Lead 
Subscription 

This  Use  Case  describes  how  a 
Recruiter  can  update  their 
current  subscriptions. 

Recruiter  (Primary  Actor) 

Candidate  (External  Server) 

13 

Delete  Candidate  Lead 
Subscription 

This  Use  Case  describes  how  a 
Recruiter  can  delete  any  of  their 
current  subscriptions. 

Recruiter  (Primary  Actor) 

Candidate  (External  Server) 

14 

Facilitate  community 
events 

This  use  case  describes  how  a 
Recruiter  manages  the  forum 
and  blog  contents  within  their 
recruiting  district. 

Recruiter  (Primary  Actor) 

Employer  (External  Server) 

Candidate  (External  Server) 

MANAGER  USE  CASES 

1 

Create  Roles  For  Users 
or  Groups  of  RBAS 

This  Use  Case  describes  how 
system  managers  control  the 
access  and  privileges  of  system 
users  by  creating  individual  and 
group  accounts. 

System  Manager  (Primary  Actor) 
Employer  (External  Receiver) 
Candidate  (External  Receiver) 
Recruiter  (External  Receiver) 

2 

Review  Roles  For  Users 
or  Groups  of  RBAS 

This  Use  Case  describes  how 
system  managers  can  review  the 
roles  and  rights  assigned  roles 
to  a  user  or  a  group. 

System  Manager  (Primary  Actor) 

3 

Update  Roles  For  Users 
or  Groups  of  RBAS 

This  Use  Case  describes  how 
system  managers  can 
update/modify  the  access  and 
capabilities  of  system 
users/groups. 

System  Manager  (Primary  Actor) 
Employer  (External  Receiver) 
Candidate  (External  Receiver) 
Recruiter  (External  Receiver) 

4 

Delete  Roles  For  Users 
or  Groups  of  RBAS 

This  Use  Case  describes  how 
system  managers  can  delete  the 
access  and  capabilities  of 
system  users/groups. 

System  Manager  (Primary  Actor) 
Employer  (External  Receiver) 
Candidate  (External  Receiver) 
Recruiter  (External  Receiver) 

5 

Create  Personal  Content 
for  Management  and 

Site  Portals 

This  Use  Case  describes  how  a 
System  Manager  can  create 
content  for  the  management 
web  portal  as  well  as  control  the 
core  content  for  the  entire 

RBAS  site. 

System  Manager  (Primary  Actor) 
Employer  (External  Receiver) 
Candidate  (External  Receiver) 
Recruiter  (External  Receiver) 

6 

Review  Management 
and  Site  Web  Portal 
Content 

This  Use  Case  describes  how  a 
System  Manager  can  review 
settings  for  both  the  Managerial 
and  Site  web  portal  for  the 
Reserve  Billet  Advertisement 
System. 

System  Manager  (Primary  Actor) 
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Id 

Use-Case  Name 

Use-Case  Description 

Participating  Actors  and  Roles 

7 

Update  Management 
and  Site  Web  Portal 
Content 

This  Use  Case  describes  how 
system  managers  can  update 
overall  system  portal  content. 

(e.g. :  broadcast  messages  to 

ALL  system  users.) 

System  Manager  (Primary  Actor) 
Employer  (External  Receiver) 
Candidate  (External  Receiver) 
Recruiter  (External  Receiver) 

8 

Delete  Management  and 
Site  Web  Portal  Content 

This  Use  Case  describes  how  a 
System  Manager  can  delete 
settings  for  the  Management  or 
Site  web  portal  for  the  Reserve 
Billet  Advertisement  System. 

System  Manager  (Primary  Actor) 
Employer  (External  Receiver) 
Candidate  (External  Receiver) 
Recruiter  (External  Receiver) 

9 

Generate  adhoc  reports 

This  Use  Case  describes  how  a 
System  Manager  generates  and 
views  ad  hoc  reports. 

System  Manager  (Primary  Actor) 

10 

Generate  detailed  user 
report 

This  Use  Case  describes  how  a 
System  Manager  generates  a 
detailed  report  on  an  individual 
user. 

System  Manager  (Primary  Actor) 

11 

Generate  system  usage 
report 

This  Use  Case  describes  how  a 
System  Manager  generates  a 
report  that  tracks  the  use  of  the 
RBAS  system. 

System  Manager  (Primary  Actor) 

12 

Generate  user  overview 
report 

This  Use  Case  describes  how  a 
System  Manager  generates  a 
report  that  displays  all  the  users 
of  a  specific  group  or  category 
that  is  registered  in  the  RBAS 
system. 

System  Manager  (Primary  Actor) 

13 

Ensure  all  form  input 
data  is  valid  and 
complete 

This  Use  Case  describes  how 
the  RBAS  system  automatically 
checks  all  input  for 
completeness  and  accuracy. 

System  (Primary  Actor) 

System  Manager  (External 

Receiver) 

Employer  (External  Receiver) 
Candidate  (External  Receiver) 
Recruiter  (External  Receiver) 

14 

Automated  Update  of 
Candidate  Table 

This  use  case  describes  how  a 
candidate's  personal  information 
gets  populated  from  MCTFS. 

System  (Primary  Actor) 

15 

Automated  Update  of 
MOS  Table 

This  use  case  describes  how  the 
MOS  table  gets  populated  from 
MCTFS. 

System  (Primary  Actor) 
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Id 

Use-Case  Name 

Use-Case  Description 

Participating  Actors  and  Roles 

16 

Perform  Limited 
Modification  to  the 
System. 

This  Use  Case  describes  how 
system  managers  will  be  able  to 
modify  limited  website  content, 
(e.g. :  change  aesthetics  of  web 
front  end,  style  sheets, 
nomenclature  e.g.  ADSW  to 
ADOS) 

Manager  (Primary  Actor) 

Candidate  (External  Receiver) 
Recruiter  (External  Receiver) 
Employer  (External  Receiver) 

17 

Ensure  that  user 
credentials  are  verified 
by  use  of  CAC  or  strong 
password  during  login 
process 

This  use  case  describes  the 
system  actions  performed  when 
a  user  logons  to  the  system. 
Credentials  will  be  verified  with 
a  Common  Access  Card  (CAC) 
or  strong  password. 

System  (Primary  Actor) 

Manager  (External  Server) 

Candidate  (External  Server) 

Recruiter  (External  Server) 

Employer  (External  Server) 

18 

Manage  Trouble  Call 
Queue 

This  Use  Case  describes  how 
managers  will  be  able  to  view 
and  manage  all  trouble  calls 
submitted  by  users  of  the 
system. 

Manager  (Primary  Actor) 

Candidate  (External  Server) 

Recruiter  (External  Server) 

EMPLOYER  USE  CASES 

1 

Create  Advertisement 

This  use-case  describes  the 
action  of  manually  inputting  a 
new  billet/advertisement  into 
the  system  to  be  viewed  by 
potential  candidates. 

Employer  (Primary  Actor) 

Candidate  (External  Receiver) 
Recruiter  (External  Receiver) 

2 

Review  Advertisement 

This  Use  Case  describes  how  an 
Employer  manually  reviews  all 
the  advertisements  they  have 
created  which  are  currently 
posted. 

Employer  (Primary  Actor) 

3 

Update  Advertisement 

This  use-case  describes  the 
action  of  updating  a  manually 
inputted  billet/advertisement  in 
the  system. 

Employer  (Primary  Actor) 

Candidate  (External  Receiver) 
Recruiter  (External  Receiver) 

4 

Delete  Advertisement 

This  use-case  describes  the 
action  of  deleting  a  manually 
inputted  billet/advertisement 
from  the  system. 

Employer  (Primary  Actor) 

Candidate  (External  Receiver) 
Recruiter  (External  Receiver) 

5 

Create  automated 
advertisement 

This  use  case  describes  how  the 
system  generates  billet 
advertisements  automatically  by 
comparing  MCTFS  O/H  data 
versus  T/O  data. 

Employer  System  (Primary  Actor) 
MCTFS/TFSMS  (External  Server) 
Recruiter  (External  Receiver) 
Candidate  (External  Receiver) 
Employer  (External  Receiver) 
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Id 

Use-Case  Name 

Use-Case  Description 

Participating  Actors  and  Roles 

6 

Create  subscription  to 
automated  candidate 
search  services 

This  Use  Case  describes  how  an 
Employer  can  create  a 
subscription  to  automatically 
receive  updates  (email  or 
notification  on  portal)  if  new 
candidates  that  fit  his  or  her 
criteria  (geo  loc,  dates,  MOS) 
have  recently  registered,  posted 
new  or  updated  information  or 
deleted  items  from  their  profile. 

Employer  (Primary  Actor) 

Candidate  (External  Server) 

7 

Review  subscription  to 
automated  candidate 
search  services 

This  Use  Case  describes  how  an 
employer  can  review  their 
subscriptions  without  making 
any  modifications  to  them. 

Employer  (Primary  Actor) 

8 

Update  subscription  to 
automated  candidate 
search  services 

This  Use  Case  describes  how  an 
employer  can  modify  their 
current  subscriptions. 

Employer  (Primary  Actor) 

Candidate  (External  Server) 

9 

Delete  subscription  to 
automated  candidate 
search  services 

This  Use  Case  describes  how  an 
employer  can  delete  any  of  their 
current  subscriptions. 

Employer  (Primary  Actor) 

Candidate  (External  Server) 

10 

View  current  application 
pool 

This  use  case  describes  how  an 
employer  can  view  all 
leads/applications  that  have 
been  submitted  for  billets  in 
their  purview. 

Employer  (Primary  Actor) 

Candidate  (External  Server) 

11 

Verify  validity  of 
automated  billet 
generation 

This  Use  Case  describes  how 
Employers  verify  the  billets 
generated  automatically  by  the 
RBAS  system. 

Employer  (Primary  Actor) 

Candidate  (External  Receiver) 
Recruiter  (External  Receiver) 

12 

Manually  search  all 
Candidates  by  avenue  of 
interest  (MOS/Dates) 

This  Use  Case  describes  how  an 
Employer  can  search  for 
interested  Candidates  that  match 
their  search  criteria. 

Employer  (Primary  Actor) 

Candidate  (External  Server) 

13 

Hire  Candidate 

This  use  case  describes  how  an 
employer  selects  a  particular 
candidate  for  a  billet. 

Employer  (Primary  Actor) 

Candidate  (External  Receiver) 
Recruiter  (External  Receiver) 

14 

Reject  Candidate 

This  use  case  describes  how  an 
employer  rejects  a  particular 
candidate  for  a  billet. 

Employer  (Primary  Actor) 

Candidate  (External  Receiver) 
Recruiter  (External  Receiver) 

15 

Communicate  with 
candidate  pool 

This  use  case  describes  how  an 
Employer  can  conduct  mass 
communication  with  all 
candidates  applying  for  a 
specific  billet. 

Employer  (Primary  Actor) 

Candidate  (External  Receiver) 

16 

Communicate  with 
potential  candidates 

This  use  case  describes  how  an 
Employer  can  conduct  mass 
communication  with  all 
candidates  who  might  be 
interested  in  a  specific  billet. 

(e.g.:  New  billet  for  a  0659 
opens  up,  employer  can 
communicate  with  all  RBAS 
users  with  06XX  MOS.) 

Employer  (Primary  Actor) 

Candidate  (External  Receiver) 
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Id 

Use-Case  Name 

Use-Case  Description 

Participating  Actors  and  Roles 

17 

Create  employer  web 
portal  content 

This  use  case  describes  how  an 
employer  can  create  a 
personalized  web  portal  upon 
initial  login. 

Employer  (Primary  Actor) 

18 

Review  employer  web 
portal  content 

This  use  case  describes  how  an 
employer  can  review  the 
customizable  information 
contained  within  their  personal 
web  portal  (e.g.:  RSS  feeds, 
content) 

Employer  (Primary  Actor) 

19 

Update  employer  web 
portal  content 

This  use  case  describes  how  an 
employer  can  update  the 
customizable  information 
contained  within  their  personal 
web  portal  (e.g.:  RSS  feeds, 
content) 

Employer  (Primary  Actor) 

20 

Delete  employer  web 
portal  content 

This  use  case  describes  how  an 
employer  can  delete  the 
customizable  information 
contained  within  their  personal 
web  portal  (e.g.:  RSS  feeds, 
content) 

Employer  (Primary  Actor) 

21 

Generate  adhoc  reports 

This  Use  Case  describes  how  an 
Employer  generates  and  views 
ad  hoc  reports. 

Employer  (Primary  Actor) 

22 

Generate  advertisement 
history 

This  use  case  describes  how  an 
employer  can  view  a  report 
which  displays  advertisement 
history  information  for  all 
current  applications. 

Employer  (Primary  Actor) 

23 

Generate  detailed 
advertisement  report 

This  use  case  describes  how  an 
employer  can  generate  a  report 
which  lists  the  details  of  all 
current  advertisements. 

Employer  (Primary  Actor) 

24 

Generate  advertisement 
response  report 

This  use  case  describes  how  an 
employer  can  view  a  report 
which  displays  advertisement 
response  information  for  all 
current  applications. 

Employer  (Primary  Actor) 

25 

Generate  timed 
report/email  (30/14/0/- 
14) 

This  use  case  describes  how  the 
system  generates  a  temporal 
report/email  which  outlines  the 
billets  that  will  expire  soon. 

Employer  System  (Primary  Actor) 
Candidate  (External  Receiver) 
Employer  (External  Receiver) 

26 

Manage  Candidate 

Leads 

This  Use  Case  describes  how  an 
Employer  can  manage  all  leads 
that  have  been  generated  for 
advertisements  that  are  included 
in  their  purview. 

Employer  (Primary  Actor) 

Candidate  (External  Server) 
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APPENDIX  B.  CANDIDATE  USE  CASES 


Candidate  Subsystem 


USE  CASE  NAME: 

Contact  employer  for  additional 
infonnation 

USE  CASE  TYPE 

PRIORITY: 

Low 

System  Analysis 

PRIMARY  BUSINESS 
ACTOR 

Candidate 

PRIMARY  SYSTEM 
ACTOR 

OTHER 

PARTICIPATING 

ACTORS: 

Employer 

DESCRIPTION: 

This  Use  Case  describes  how  a  candidate  can  contact  an  employer  for 
additional  information  about  an  advertisement. 

PRE-CONDITION: 

The  candidate  is  registered  in  the  Reserve  Billet  Advertisement  System  and 
has  been  assigned  the  appropriate  level  of  access. 

TRIGGER: 

Candidate  clicks  on  contact  employer  link  within  an  advertisement. 

TYPICAL  COURSE 

Actor  Action 

System  Response 

OF  EVENTS: 


Step  1 :  Candidate  actuates 
additional  information  link 
within  an  advertisement. 


Step  3:  The  user  inputs  desired 
request  and  clicks  “submit”. 


Step  2:  System  opens  a  request  form 
window. 


Step  4:  System  checks  validity  of 
information  and  transmits  an  email  and 
presents  a  success  message. 


ALTERNATE 

COURSES: 


AA  Step  3:  System  reports  error  if  link  is  not  operational.  Error  message  is 
displayed. 


SR  Step  4  :  If  information  is  not  valid,  system  reports  error  to  user. 


AA  Step  5:  User  corrects  information  and  clicks  submit.  Process  re-enters 
at  step  4. 


CONCLUSION: 


Candidate  has  successfully  transmitted  information  request  to  employer. 


POST-CONDITION: 


User  is  returned  to  portal  homepage. 


BUSINESS  RULES 


IMPLEMENTATION 
CONTRAINTS  AND 
SPECIFICATIONS 


ASSUMPTIONS: 


User  must  have  access  to  NMCI  compliant  web  browser. 


Contact  Employer  Process  Model 


Additional 

Information 

Ro|..i-vU’il 


Candidate 


Employer's 

Email 

Response 


Email 

Information 

Requested 


Contact 

Employer 


Employer's 

Response 
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Candidate  Subsystem 


USE  CASE  NAME: 

Create  Application 

USE  CASE  TYPE 

System  Analysis 

PRIORITY: 

High 

SOURCE: 

System  Requirement 

PRIMARY  BUSINESS 
ACTOR 

Candidate 

PRIMARY  SYSTEM 
ACTOR 

OTHER 

PARTICIPATING 

ACTORS: 

Employer 

Recruiter 

DESCRIPTION: 

This  Use  Case  describes  how  a  candidate  applies  for  an  advertised  billet. 

PRE-CONDITION: 

The  candidate  is  registered  in  the  Reserve  Billet  Advertisement  System  and 
has  been  assigned  the  appropriate  level  of  access. 

TRIGGER: 

The  Use  Case  is  initiated  when  the  candidate  submits  an  application. 

TYPICAL  COURSE 

OF  EVENTS: 

Actor  Action 

System  Response 

Step  1 :  The  candidate  applies 
for  a  billet  advertised  on  the 
website  by  clicking  on  the 
hyper  link  or  “apply  for”  button 
associated  with  the  desired 
billet. 

Step  2:  The  system  verifies  that  all  of  the 
required  fields  are  filled  out  in  the  input 
form. 

Step  3:  The  system  verifies  that  the  billet 
being  applied  for  is  still  valid. 

Step  5:  The  candidate  responds 
positively  to  system  prompt. 

Step  4:  System  prompts  user  on  whether 
they  are  sure  that  they  want  to  submit  this 
application. 

Step  6:  The  system  accepts  the 
application  and  stores  it. 

Step  7:  The  system  updates  the 
applicable  employer  application  queue 
for  that  billet. 

Step  8:  The  system  generates  leads  for 
Employers  and  Recruiters  that  have 
subscribed  to  automated  candidate  search 
services. 

Step  9:  The  system  generates  a  tickler 
email  for  the  employer  advertising  the 
billet  and  the  recruiter  in  the  appropriate 
district. 

Step  10:  The  system  generates  an  email 
for  the  candidate  acknowledging  the 
systems  acceptance  of  their  application. 

ALTERNATE 

COURSES: 

SR  Step  3:  All  the  required  information  not  present,  error  message  sent  to 
user. 

AA  Step  4:  Candidate  corrects  the  error  and  resubmits. 

Return  to  step  4  of  the  “Typical  Course  of  Events” 

OR 

AA  Step  5:  The  candidate  responds  negatively  to  system  prompt  and 
request  is  canceled. 
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Candidate  Subsystem 


USE  CASE  NAME: 

Update  Application 

USE  CASE  TYPE 

System  Analysis 

PRIORITY: 

High 

SOURCE: 

System  Requirement 

PRIMARY  BUSINESS 
ACTOR 

Candidate 

PRIMARY  SYSTEM 
ACTOR 

OTHER 

PARTICIPATING 

ACTORS: 

Employer 

Recruiter 

DESCRIPTION: 

This  Use  Case  describes  how  a  Reservist  updates  a  current  application  that 
was  submitted. 

PRE-CONDITION: 

The  candidate  is  registered  in  the  Reserve  Billet  Advertisement  System  and 
has  been  assigned  the  appropriate  level  of  access. 

The  candidate  currently  has  at  least  one  active  application. 

TRIGGER: 

The  candidate  selects  an  application  to  update  from  their  queue. 

TYPICAL  COURSE 

OF  EVENTS: 

Actor  Action 

System  Response 

Step  1 :  The  candidate  selects 
an  application  to  update  from 
their  queue  by  clicking  on  the 
hyperlink  or  the  update  button 
associated  with  that  application. 

Step  2:  The  system  checks  the  status  of 
the  application  that  the  candidate  desires 
to  update. 

Step  3:  If  the  application  has  not  been 
selected  or  being  processed  and  the 
information  is  not  personal  information 
housed  in  MCTFS,  the  system  will  honor 
the  update  request  of  the  candidate. 

Step  4:  The  system  generates  an  email  to 
the  candidate  that  acknowledges  the 
success  of  the  update  operation. 

Step  5:  A  tickler  email  is  sent  to  the 
Employer  and  Recruiter  notifying  them 
of  the  change. 

ALTERNATE 

COURSES: 

Step  3 :  If  the  update  requested  is  personal  information  the  candidate  will  be 
directed  to  services  provided  by  Marine  OnLine  (MOL)  to  complete  the 
transaction. 

CONCLUSION: 

The  application  is  successfully  updated  the  information  that  required 
changes. 

POST-CONDITION: 

User  is  returned  to  portal  homepage. 

BUSINESS  RULES 

1 .  Application  can  be  updated  as  long  as  the  application  is  in  the  pre¬ 
approval  status. 

2.  The  candidate  cannot  update  personal  information  without  going  through 
the  appropriate  channels. 

IMPLEMENTATION 
CONTRAINTS  AND 
SPECIFICATIONS 

ASSUMPTIONS: 

User  must  have  access  to  NMCI  compliant  web  browser. 
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Candidate  Subsystem 


USE  CASE  NAME: 

Delete  Application 

USE  CASE  TYPE 

System  Analysis 

PRIORITY: 

High 

SOURCE: 

System  Requirement 

PRIMARY  BUSINESS 
ACTOR 

Candidate 

PRIMARY  SYSTEM 
ACTOR 

OTHER 

PARTICIPATING 

ACTORS: 

Employer 

Recruiter 

DESCRIPTION: 

This  Use  Case  describes  how  a  Reservist  deletes  an  application  that  has 
been  previously  submitted. 

PRE-CONDITION: 

The  candidate  is  registered  in  the  Reserve  Billet  Advertisement  System  and 
has  been  assigned  the  appropriate  level  of  access. 

The  candidate  currently  has  at  least  one  active  application. 

TRIGGER: 

The  candidate  selects  an  application  that  they  want  to  delete. 

TYPICAL  COURSE 

OF  EVENTS: 

Actor  Action 

System  Response 

Step  1 :  The  candidate  selects 
an  application  to  delete  from 
their  queue  by  clicking  on  the 
hyper  link  or  the  delete  button 
associated  with  that  application. 

Step  2:  The  system  checks  the  status  of 
the  application  that  the  candidate  wishes 
to  delete. 

Step  3:  If  the  application  has  not  been 
selected  and  being  processed,  the  system 
will  honor  the  delete  request  of  the 
candidate. 

Step  4:  The  employer’s  application 
queue  for  this  advertisement  is  updated. 

Step  5:  The  candidate’s  active 
application  queue  is  updated. 

Step  5:  A  tickler  email  is  sent  to  the 
Employer  notifying  them  of  the  deletion. 

Step  6:  The  system  generates  an  email  to 
the  candidate  that  acknowledges  the 
success  of  the  delete  operation. 

Step  7:  A  tickler  email  is  sent  to  the 
Employer  and  Recruiter  notifying  them 
of  the  deletion. 

ALTERNATE 

COURSES: 

Step  3 :  If  the  application  has  been  selected  and  being  processed  therefore 
the  system  will  NOT  honor  the  delete  request  of  the  candidate. 

CONCLUSION: 

The  application  is  deleted  and  the  candidate’s  active  application  queue  is 
updated. 

POST-CONDITION: 

User  is  returned  to  portal  homepage. 

BUSINESS  RULES 

Application  can  be  updated  as  long  as  the  application  is  in  the  pre-approval 
status. 

The  candidate  cannot  update  personal  information  without  going  through 
the  appropriate  channels. 

IMPLEMENTATION 
CONTRAINTS  AND 
SPECIFICATIONS 

ASSUMPTIONS: 

User  must  have  access  to  NMCI  compliant  web  browser. 
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Candidate  Subsystem 


USE  CASE  NAME: 

Create  Billet  Lead  Subscription 

USE  CASE  TYPE 

System  Analysis 

PRIORITY: 

Medium 

SOURCE: 

Requirements  Analysis 

PRIMARY  BUSINESS 
ACTOR 

Candidate 

PRIMARY  SYSTEM 
ACTOR 

OTHER 

PARTICIPATING 

ACTORS: 

Employer 

Recruiter 

DESCRIPTION: 

This  Use  Case  describes  how  a  Candidate  can  create  a  subscription  to 
receive  updates  (email  or  notification  on  portal)  if  new  billets  that  fit  his  or 
her  criteria  (geo  loc,  dates)  have  been  posted,  updated  or  deleted. 

PRE-CONDITION: 

The  candidate  is  registered  in  the  Reserve  Billet  Advertisement  System  and 
has  been  assigned  the  appropriate  level  of  access. 

TRIGGER: 

The  candidate  wants  to  create  a  subscription  service  within  RBAS. 

TYPICAL  COURSE 

OF  EVENTS: 

Actor  Action 

System  Response 

Step  1 :  Candidate  with  roles 
clicks  “Create  Subscription” 

Step  2:  Screen  with  subscription  criteria 
(MOS,  GeoLoc,  Dates)  appears  for 
candidate  to  select  or  input. 

Step  3 :  Candidate  completes 
form  and  clicks  submit. 

Step  4:  The  system  verifies  the 
information. 

Step  5:  If  the  information  is  correct,  the 
system  accepts  the  subscription. 

Step  6:  The  system  places  the  employer 
and  their  search  criteria  in  its 
subscription  queue. 

Step  7:  Leads  are  generated  for 
employers  and  recruiters  that  have 
subscribed  to  candidate  search  services. 

Step  8:  The  system  compares  the  criteria 
of  newly  posted,  updated  or  deleted 
billets  versus  the  criteria  posted  by 
subscribers. 

ALTERNATE 

COURSES: 

SR  Step  2:  The  system  rejects  the  application  because  of  incomplete  or 
improper  data. 

AA  Step  3:  The  user  corrects  the  data,  resubmits  and  reenters  the  process  at 
step  #2  of  the  “typical  course  of  events.” 

CONCLUSION: 

Candidate  has  successfully  created  a  subscription  service  to  receive  leads 
automatically. 

POST-CONDITION: 

User  is  returned  to  portal  homepage. 

BUSINESS  RULES 

IMPLEMENTATION 
CONTRAINTS  AND 
SPECIFICATIONS 

ASSUMPTIONS: 

User  must  have  access  to  NMCI  compliant  web  browser. 
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Candidate  Subsystem 


USE  CASE  NAME: 

Review  Billet  Lead  Subscription 

USE  CASE  TYPE 

System  Analysis 

PRIORITY: 

Medium 

SOURCE: 

Requirements  Analysis 

PRIMARY  BUSINESS 
ACTOR 

Candidate 

PRIMARY  SYSTEM 
ACTOR 

OTHER 

PARTICIPATING 

ACTORS: 

DESCRIPTION: 

This  Use  Case  describes  how  a  Candidate  can  review  all  active 
subscriptions. 

PRE-CONDITION: 

The  candidate  is  registered  in  the  Reserve  Billet  Advertisement  System  and 
has  been  assigned  the  appropriate  level  of  access. 

The  candidate  has  active  subscription(s). 

TRIGGER: 

The  candidate  chooses  to  review  an  active  subscription  in  the  RBAS 
subscription  portal. 

TYPICAL  COURSE 

Actor  Action 

System  Response 

OF  EVENTS: 


Step  1 :  The  candidate  selects 
“view”  subscription  from  menu 
of  choices. 


Step  2:  The  system  will  query  the 
database  to  retrieve  the  candidate’s 
subscription  information. 


Step  3:  Once  an  active  record  is  found, 
the  system  will  display  the  retrieved 
subscription  information. 


ALTERNATE 

COURSES: 


SR  Step  3  :  The  system  is  unable  to  locate  a  subscription  for  the  candidate. 


SR  Step  4  :  The  system  displays  an  error  message  that  informs  the  candidate 
that  he  or  she  has  no  active  subscriptions. 


CONCLUSION: 


Candidate  successfully  reviews  active  subscriptions. 


POST-CONDITION: 


User  is  returned  to  portal  homepage. 


BUSINESS  RULES 


IMPLEMENTATION 
CONTRAINTS  AND 
SPECIFICATIONS 


ASSUMPTIONS: 


User  must  have  access  to  NMCI  compliant  web  browser. 


Review  Subscription  Process  Model 


Request 
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Candidate  Subsystem 


USE  CASE  NAME: 

Update  Billet  Lead  Subscription 

USE  CASE  TYPE 

System  Analysis 

PRIORITY: 

Medium 

SOURCE: 

Requirements  Analysis 

PRIMARY  BUSINESS 
ACTOR 

Candidate 

PRIMARY  SYSTEM 
ACTOR 

OTHER 

PARTICIPATING 

ACTORS: 

Employer 

Recruiter 

DESCRIPTION: 

This  Use  Case  describes  how  a  Candidate  can  update  an  active  subscription. 

PRE-CONDITION: 

The  candidate  is  registered  in  the  Reserve  Billet  Advertisement  System  and 
has  been  assigned  the  appropriate  level  of  access. 

The  candidate  has  active  subscription(s). 

TRIGGER: 

The  candidate  chooses  to  update  an  active  subscription  in  the  RBAS 
subscription  portal. 

TYPICAL  COURSE 

OF  EVENTS: 

Actor  Action 

System  Response 

Step  1 :  The  candidate  selects 
“update”  subscription  from 
menu  of  choices. 

Step  2:  The  system  will  query  the 
database  to  retrieve  the  candidate’s 
subscription  information. 

Step  3:  Once  an  active  record  is  found, 
the  system  will  prompt  candidate  to 
verify  if  the  information  retrieved  is  the 
subscription  they  want  to  update. 

Step  4:  The  candidate  verifies 
the  information  and 
acknowledges  by  pressing 
continue. 

Step  5:  The  system  then  opens  a 
subscription  edit  window  and  populates 
the  fields  with  the  retrieved  information 
and  prompts  the  user  to  update  the 
subscription. 

Step  6:  The  candidate  updates 
the  information  and  hits 
“submit”  when  complete. 

Step  7:  The  system  error  checks  the 
information,  if  the  information  is  correct 
the  update  is  accepted,  acknowledged 
and  the  database  is  updated. 

Step  8:  The  system  places  the  candidate 
and  their  search  criteria  in  its 
subscription  queue. 

Step  9:  Leads  are  generated  for 
employers  and  recruiters  that  have 
subscribed  to  candidate  search  services. 

Step  10:  The  system  compares  the  billet 
identifiers  of  newly  posted,  updated  or 
deleted  jobs  versus  the  criteria  posted  by 
subscribers. 

Step  11:  If  the  search  criteria  matches,  an 
email  is  generated  and  sent  to  the 
candidate  or  his  portal  is  updated,  (which 
ever  method  is  selected) 
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ALTERNATE 

COURSES: 


SR  Step  3  :  The  system  is  unable  to  locate  a  subscription  for  the  candidate. 


SR  Step  4  :  The  system  displays  an  error  message  that  informs  the  candidate 
that  he  or  she  has  no  active  subscriptions. 


AA  Step  6:  The  candidate  declines  to  update  the  subscription. 


SR  Step  7  :  The  system  acknowledges  the  negative  response  and  deletes  the 
transaction. 


SR  Step  8  :  The  system  display  successful  cancelation  message  to  user. 


CONCLUSION: 


The  candidate  updates  an  active  subscription. 


POST-CONDITION: 


User  is  returned  to  portal  homepage. 


BUSINESS  RULES 


IMPLEMENTATION 
CONTRAINTS  AND 
SPECIFICATIONS 


ASSUMPTIONS: 


User  must  have  access  to  NMCI  compliant  web  browser. 


Update  Subscription  Process  Model 
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Candidate  Subsystem 


USE  CASE  NAME: 

Delete  Billet  Lead  Subscription 

USE  CASE  TYPE 

System  Analysis 

PRIORITY: 

Medium 

SOURCE: 

Requirements  Analysis 

PRIMARY  BUSINESS 
ACTOR 

Candidate 

PRIMARY  SYSTEM 
ACTOR 

OTHER 

PARTICIPATING 

ACTORS: 

Employer 

Recruiter 

DESCRIPTION: 

This  Use  Case  describes  how  a  Candidate  can  delete  an  active  subscription. 

PRE-CONDITION: 

The  candidate  is  registered  in  the  Reserve  Billet  Advertisement  System  and 
has  been  assigned  the  appropriate  level  of  access. 

The  candidate  has  active  subscriptions. 

TRIGGER: 

The  candidate  chooses  to  delete  an  active  subscription  in  the  RBAS 
subscription  portal. 

TYPICAL  COURSE 

OF  EVENTS: 

Actor  Action 

System  Response 

Step  1 :  The  candidate  selects 
“delete”  subscription  from 
menu  of  choices. 

Step  2:  The  system  will  query  the 
database  to  retrieve  the  candidate’s 
subscription  information. 

Step  3:  Once  an  active  record  is  found, 
the  system  will  prompt  candidate  to 
verify  if  the  information  retrieved  is  the 
subscription  they  want  deleted. 

Step  4:  The  candidate  verifies 
the  information  and 
acknowledges  by  pressing 
continue. 

Step  5:  The  system  then  prompts  the 
candidate  if  they  are  certain  they  want  to 
cancel  this  subscription. 

Step  6:  The  candidate 
acknowledges  his  or  her 
approval  by  clicking  “yes” 

Step  7:  The  system  receives  the  response 
and  deletes  the  subscription  from  the 
database 

Step  8:  A  success  message  is  generated 
and  displayed  to  the  candidate. 

ALTERNATE 

COURSES: 

SR  Step  3:  The  system  is  unable  to  locate  a  subscription  for  the  candidate. 

SR  Step  4:  The  system  displays  an  error  message  that  informs  the  candidate 
that  he  or  she  has  no  active  subscriptions. 

AA  Step  6:  The  candidate  declines  to  delete  subscription. 

SR  Step  7:  The  system  acknowledges  the  negative  response  and  deletes  the 
transaction. 

SR  Step  8:  The  system  display  successful  cancelation  message  to  user. 

CONCLUSION: 

The  candidate  deletes  an  active  subscription. 

POST-CONDITION: 

User  is  returned  to  portal  homepage. 

BUSINESS  RULES 

IMPLEMENTATION 
CONTRAINTS  AND 
SPECIFICATIONS 

ASSUMPTIONS: 

User  must  have  access  to  NMCI  compliant  web  browser. 
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Candidate  Subsystem 


USE  CASE  NAME: 

Create  personal  web  portal  content 

USE  CASE  TYPE 

System  Analysis 

PRIORITY: 

Medium 

SOURCE: 

Requirements  Analysis 

PRIMARY  BUSINESS 
ACTOR 

Candidate 

PRIMARY  SYSTEM 
ACTOR 

OTHER 

PARTICIPATING 

ACTORS: 

DESCRIPTION: 

This  use  case  describes  how  a  candidate  can  create  a  personalized  web 
portal  upon  initial  login  to  the  Reserve  Billet  Advertisement  System. 

PRE-CONDITION: 

The  candidate  is  registered  in  the  Reserve  Billet  Advertisement  System  and 
has  been  assigned  the  appropriate  level  of  access. 

TRIGGER: 

The  candidate  subscribes  to  service  via  RBAS. 

TYPICAL  COURSE 

OF  EVENTS: 

Actor  Action 

System  Response 

Step  1 :  The  candidate  logons  to 
RBAS  for  the  first  time. 

Step  2:  The  system  prompts  the  user  to 
select  what  content  they  want  to  add  to 
their  personal  portal.  The  user  will  be 
provided  with  a  list  of  alternatives  to 
select  from. 

Step  3:  The  candidate  selects 
the  services  that  he  or  she  wants 
to  populate  their  personal  portal 
with.  When  the  candidate  is 
done  choosing,  he  or  she  hits 
“submit”  to  transmit  settings 
back  to  RBAS. 

Step  4:  RBAS  acknowledges  the  request, 
and  updates  the  candidate’s  preferences 
queue  and  updates  the  database. 

Step  5:  The  system  sends  a  positive 
response  acknowledging  changes  and 
instructs  user  to  log  off  and  on  to  view 
the  changes. 

ALTERNATE 

COURSES: 

None 

CONCLUSION: 

The  candidate  personalizes  their  web  portal. 

POST-CONDITION: 

User  is  returned  to  portal  homepage. 

BUSINESS  RULES 

IMPLEMENTATION 
CONTRAINTS  AND 
SPECIFICATIONS 

ASSUMPTIONS: 

User  must  have  access  to  NMCI  compliant  web  browser. 
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Create  Portal  Settings  Process  Model 
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Candidate  Subsystem 


USE  CASE  NAME: 

Review  personal  web  portal  content 

USE  CASE  TYPE 

System  Analysis 

PRIORITY: 

Medium 

SOURCE: 

Requirements  Analysis 

PRIMARY  BUSINESS 
ACTOR 

Candidate 

PRIMARY  SYSTEM 
ACTOR 

OTHER 

PARTICIPATING 

ACTORS: 

DESCRIPTION: 

This  use  case  describes  how  a  candidate  can  review  settings  for  their 
personalized  web  portal  in  Reserve  Billet  Advertisement  System. 

PRE-CONDITION: 

The  candidate  is  registered  Reserve  Billet  Advertisement  System  and  have 
been  assigned  the  appropriate  level  of  access. 

The  candidate  is  logged  into  RBAS. 

TRIGGER: 

The  candidate  reviews  personal  setting  for  personal  portal  in  RBAS. 

TYPICAL  COURSE 

OF  EVENTS: 

Actor  Action 

System  Response 

Step  1 :  The  candidate  selects 
“view”  portal  settings  from 
menu  of  choices. 

Step  2:  The  system  queries  the  database 
for  the  candidate’s  currents  settings. 

Step  3:  If  the  candidate  has  personal 
settings,  RBAS  displays  the  queries 
results. 

ALTERNATE 

COURSES: 

SR  Step  3:  The  candidate  doesn’t  have  any  portal  settings  and  the  system 
displays  an  error  message. 

CONCLUSION: 

The  candidate  reviews  their  personal  web  portal  settings. 

POST-CONDITION: 

User  is  returned  to  portal  homepage. 

BUSINESS  RULES 

IMPLEMENTATION 
CONTRAINTS  AND 
SPECIFICATIONS 

ASSUMPTIONS: 

User  must  have  access  to  NMCI  compliant  web  browser. 
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Candidate  Subsystem 


USE  CASE  NAME: 

Update  personal  web  portal  content 

USE  CASE  TYPE 

System  Analysis 

PRIORITY: 

Medium 

SOURCE: 

Requirements  Analysis 

PRIMARY  BUSINESS 
ACTOR 

Candidate 

PRIMARY  SYSTEM 
ACTOR 

OTHER 

PARTICIPATING 

ACTORS: 

DESCRIPTION: 

This  use  case  describes  how  a  candidate  can  update  their  personalized  web 
portal  in  the  Reserve  Billet  Advertisement  System. 

PRE-CONDITION: 

The  candidate  is  registered  in  the  Reserve  Billet  Advertisement  System  and 
has  been  assigned  the  appropriate  level  of  access. 

The  candidate  is  logged  into  RBAS. 

TRIGGER: 

The  candidate  chooses  to  update  their  personal  web  portal  content  in  RBAS. 

TYPICAL  COURSE 

OF  EVENTS: 

Actor  Action 

System  Response 

Step  1 :  The  candidate  selects 
“update”  portal  settings  from 
menu  of  choices. 

Step  2:  The  system  queries  the  database, 
populates  the  list  of  alternatives  with 
current  settings. 

Step  3:  The  system  prompts  the 
candidate  to  update  their  selections. 

Step  3:  The  candidate  selects 
the  services  that  he  or  she  wants 
to  populate  their  personal  portal 
with.  When  the  candidate  is 
done  modifying  their  settings 
he  or  she  hits  “submit”  to 
transmit  settings  back  to  RBAS. 

Step  4:  RBAS  acknowledges  the  request, 
and  updates  the  member’s  preferences 
queue  and  updates  the  database. 

Step  5:  The  system  sends  a  positive 
response  acknowledging  the  changes  and 
instructs  user  to  log  off  and  on  to  view 
the  changes. 

ALTERNATE 

COURSES: 

SR  Step  2:  The  system  is  query  results  are  negative. 

SR  Step  3:  The  system  presents  and  error  message  informing  the  candidate 
and  asks  the  user  if  they  would  like  to  personalize  their  portal. 

AA  Step  4:  If  the  candidate  provides  a  positive  acknowledgement  they 
proceed  to  step  2  of  the  Create  Personal  Portal  Content.  If  not,  the 
transaction  is  cancelled. 

CONCLUSION: 

The  candidate  updates  their  settings  for  their  personalized  web  portal. 

POST-CONDITION: 

User  is  returned  to  portal  homepage. 

BUSINESS  RULES 

IMPLEMENTATION 
CONTRAINTS  AND 
SPECIFICATIONS 

ASSUMPTIONS: 

User  must  have  access  to  NMCI  compliant  web  browser. 
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Update  Portal  Settings  Process  Model 
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Candidate  Subsystem 


USE  CASE  NAME: 

Delete  personal  web  portal  content 

USE  CASE  TYPE 

System  Analysis 

PRIORITY: 

Medium 

SOURCE: 

Requirements  Analysis 

PRIMARY  BUSINESS 
ACTOR 

Candidate 

PRIMARY  SYSTEM 
ACTOR 

OTHER 

PARTICIPATING 

ACTORS: 

DESCRIPTION: 

This  use  case  describes  how  a  candidate  can  delete  settings  for  their 
personalized  web  portal  in  Reserve  Billet  Advertisement  System. 

PRE-CONDITION: 

The  candidate  is  registered  in  the  Reserve  Billet  Advertisement  System  and 
has  been  assigned  the  appropriate  level  of  access. 

TRIGGER: 

The  candidate  chooses  to  delete  their  personal  web  portal  settings. 

TYPICAL  COURSE 

Actor  Action 

System  Response 

OF  EVENTS: 


Step  1 :  The  candidate  selects 
“delete”  portal  settings  from 
menu  of  choices. 


Step  4:  The  candidate 
acknowledges  the  system 
prompt. 


Step  2:  The  system  queries  the  database 
for  the  candidate’s  currents  settings. 


Step  3:  If  the  candidate  has  personal 
settings,  RBAS  displays  the  query  results 
and  prompts  the  user  to  verify  that  they 
want  to  delete  these  settings. 


Step  5:  The  system  deletes  the  user’s 
personal  settings  and  restores  the 
system’s  default  settings. 


ALTERNATE 

COURSES: 


SR  Step  3  :  The  candidate  doesn’t  have  any  portal  settings  and  the  system 
displays  an  error  message  and  transaction  is  canceled. 


CONCLUSION: 


The  candidate  deletes  personal  web  portal  settings. 


POST-CONDITION: 


User  is  returned  to  portal  homepage. 


BUSINESS  RULES 


IMPLEMENTATION 
CONTRAINTS  AND 
SPECIFICATIONS 


ASSUMPTIONS: 


User  must  have  access  to  NMCI  compliant  web  browser. 


Delete  Portal  Settings  Process  Model 


Delete 
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Candidate  Subsystem 


USE  CASE  NAME: 

Use  External  Marine  Corps  Services 

USE  CASE  TYPE 

System  Analysis 

PRIORITY: 

Medium 

SOURCE: 

Requirements  Analysis 

PRIMARY  BUSINESS 
ACTOR 

Candidate 

PRIMARY  SYSTEM 
ACTOR 

OTHER 

PARTICIPATING 

ACTORS: 

DESCRIPTION: 

This  Use  Case  describes  how  a  Candidate  can  use  external  links  to  manage 
their  career. 

PRE-CONDITION: 

Candidate  has  successfully  logged  onto  RBAS. 

TRIGGER: 

Candidate  clicks  on  an  external  link. 

TYPICAL  COURSE 

OF  EVENTS: 

Actor  Action 

System  Response 

Step  1 :  Candidate  actuates  an 
external  link. 

Step  2:  System  opens  another  display 
window. 

Step  3:  System  opens  requested  resource. 

ALTERNATE 

COURSES: 

Step  3:  System  reports  error  if  link  is  not  operational. 

CONCLUSION: 

Candidate  has  successfully  navigated  to  desired  external  site. 

POST-CONDITION: 

User  is  returned  to  portal  homepage. 

BUSINESS  RULES 

IMPLEMENTATION 
CONTRAINTS  AND 
SPECIFICATIONS 

ASSUMPTIONS: 

User  must  have  access  to  NMCI  compliant  web  browser. 
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Candidate  Subsystem 


USE  CASE  NAME: 

Review  Application  History 

USE  CASE  TYPE 

System  Analysis 

PRIORITY: 

Medium 

SOURCE: 

Requirements  Analysis 

PRIMARY  BUSINESS 
ACTOR 

Candidate 

PRIMARY  SYSTEM 
ACTOR 

OTHER 

PARTICIPATING 

ACTORS: 

DESCRIPTION: 

This  use  case  describes  how  a  Candidate  can  review  all  applications 
submitted  via  RBAS. 

PRE-CONDITION: 

The  candidate  is  registered  in  the  Reserve  Billet  Advertisement  System  and 
has  been  assigned  the  appropriate  level  of  access. 

The  candidate  has  applied  for  vacant  billet(s). 

TRIGGER: 

The  candidate  reviews  application  history  in  RBAS. 

TYPICAL  COURSE 

Actor  Action 

System  Response 

OF  EVENTS: 


Step  1 :  The  candidate  selects 
“view”  previous  applications 
from  menu  of  choices. 


Step  2:  The  system  will  query  the 
database  to  retrieve  the  candidate’s 
previous  applications. 


Step  3:  The  system  will  display  the 
Candidate’s  application  history. 


ALTERNATE 

COURSES: 


SR  Step  3  :  The  system  query  returns  with  a  negative  response. 


SR  Step  4  :  The  system  displays  an  error  message  that  informs  the  candidate 
that  he  or  she  has  no  previous  applications  on  file. 


CONCLUSION: 


The  candidate  views  all  previous  applications  submitted. 


POST-CONDITION: 


User  is  returned  to  portal  homepage. 


BUSINESS  RULES 


IMPLEMENTATION 
CONTRAINTS  AND 
SPECIFICATIONS 


ASSUMPTIONS: 


User  must  have  access  to  NMCI  compliant  web  browser. 


Review  Application  History  Process  Model 
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Candidate  Subsystem 


USE  CASE  NAME: 

Participate  in  community  events 

USE  CASE  TYPE 

System  Analysis 

PRIORITY: 

Low 

SOURCE: 

Requirements  Analysis 

PRIMARY  BUSINESS 
ACTOR 

Candidate 

PRIMARY  SYSTEM 
ACTOR 

OTHER 

PARTICIPATING 

ACTORS: 

Employer 

Recruiter 

DESCRIPTION: 

This  Use  Case  describes  how  a  Candidate  can  use  the  community  tools 
available  in  the  RBAS  system. 

PRE-CONDITION: 

The  candidate  is  registered  in  the  Reserve  Billet  Advertisement  System  and 
has  been  assigned  the  appropriate  level  of  access. 

TRIGGER: 

Candidate  clicks  on  community  tool  of  choice. 

TYPICAL  COURSE 

Actor  Action 

System  Response 

OF  EVENTS: 


Step  1 :  Candidate  actuates  a 
community  tool  of  choice  from 
the  Candidate  Menu. 


Step  2:  System  opens  another  display 
window. 


Step  3:  System  opens  requested  resource. 


ALTERNATE 

COURSES: 


CONCLUSION: 


When  reservist  has  successfully  navigated  to  desired  community  resource. 


POST-CONDITION: 


User  is  returned  to  portal  homepage. 


BUSINESS  RULES 


IMPLEMENTATION 
CONTRAINTS  AND 
SPECIFICATIONS 


ASSUMPTIONS: 


User  must  have  access  to  NMCI  compliant  web  browser. 
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Candidate  Subsystem 


USE  CASE  NAME: 

Search  Available  Advertisements 

USE  CASE  TYPE 

System  Analysis 

PRIORITY: 

High 

SOURCE: 

Requirements  Analysis 

PRIMARY  BUSINESS 
ACTOR 

Candidate 

PRIMARY  SYSTEM 
ACTOR 

OTHER 

PARTICIPATING 

ACTORS: 

Employers 

DESCRIPTION: 

This  Use  Case  describes  how  a  Candidate  can  search  for  jobs  posted  by 
Employers  that  match  their  search  criteria. 

PRE-CONDITION: 

The  candidate  is  registered  in  the  Reserve  Billet  Advertisement  System  and 
has  been  assigned  the  appropriate  level  of  access. 

TRIGGER: 

Candidate  conducts  a  search  of  billets. 

TYPICAL  COURSE 

OF  EVENTS: 

Actor  Action 

System  Response 

Step  1 :  Candidate  enters  search 
criteria  into  query  form  and 
clicks  “submit”. 

Step  2:  System  verifies  the  data  entered 
into  search  form. 

Step  3:  If  the  information  is  complete, 
the  system  accepts  the  request  and 
conducts  the  search. 

Step  4:  System  displays  matching  billet 
information  to  the  candidate. 

ALTERNATE 

COURSES: 

SR  Step  3:  System  displays  an  error  screen  if  no  billets  match  and  prompts 
user  to  correct 

AA  Step  4:  Candidate  reenters  data,  resubmits  and  the  process  begins  at 
step  #2  of  “typical  course  of  events.” 

OR 

SR  Step  3:  System  displays  an  error  screen  if  information  is  incomplete  and 
prompts  user  to  correct  and  reenter  data. 

AA  Step  4:  Candidate  reenters  data,  resubmits  and  the  process  begins  at 
step  #2  of  “typical  course  of  events.” 

CONCLUSION: 

The  candidate  is  presented  with  the  results  of  his  or  her  query. 

POST-CONDITION: 

User  is  returned  to  portal  homepage. 

BUSINESS  RULES 

IMPLEMENTATION 
CONTRAINTS  AND 
SPECIFICATIONS 

ASSUMPTIONS: 

User  must  have  access  to  NMCI  compliant  web  browser. 
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Candidate  Subsystem 


USE  CASE  NAME: 

View  applicant  pool  for  an  active 
advertisement 

USE  CASE  TYPE 

System  Analysis 

PRIORITY: 

Medium 

SOURCE: 

Requirements  Analysis 

PRIMARY  BUSINESS 
ACTOR 

Candidate 

PRIMARY  SYSTEM 
ACTOR 

OTHER 

PARTICIPATING 

ACTORS: 

DESCRIPTION: 

This  use  case  describes  how  a  candidate  can  view  the  current  details  of  an 
active  advertisement  with  respect  to  other  candidates  that  have  applied  for  a 
billet. 

PRE-CONDITION: 

The  candidate  is  registered  Reserve  Billet  Advertisement  System  and  have 
been  assigned  the  appropriate  level  of  access. 

TRIGGER: 

The  candidate  clicks  on  an  active  advertisement  and  views  the  number  and 
qualifications  of  applicants  for  that  particular  billet. 

TYPICAL  COURSE 

Actor  Action 

System  Response 

OF  EVENTS: 


Step  1 :  The  candidate  selects 
“applicants”  from  an  active 
advertisement. 


Step  2:  The  system  will  query  the 
database  to  retrieve  the  applicant  queue 
for  the  selected  advertisement. 


Step  3:  The  system  will  display  all 
activity  associated  with  that  particular 
advertisement. 


ALTERNATE 

COURSES: 


CONCLUSION: 


The  candidate  views  activity  associated  with  an  advertisement. 


POST-CONDITION: 


User  is  returned  to  portal  homepage. 


BUSINESS  RULES 


IMPLEMENTATION 
CONTRAINTS  AND 
SPECIFICATIONS 


ASSUMPTIONS: 


User  must  have  access  to  NMCI  compliant  web  browser. 


Review  Application  Pool  Process  Model 


Query  For 


Query 


Application 
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Candidate  Subsystem 


USE  CASE  NAME: 

Create  Reserve  Qualification  Summary 

USE  CASE  TYPE 

System  Analysis 

PRIORITY: 

High 

SOURCE: 

Requirements  Analysis 

PRIMARY  BUSINESS 
ACTOR 

Candidate 

PRIMARY  SYSTEM 
ACTOR 

OTHER 

PARTICIPATING 

ACTORS: 

Employer 

Recruiter 

DESCRIPTION: 

This  use  case  describes  how  a  candidate  can  create  an  electronic  Reserve 
Qualification  Summary  (RQS). 

PRE-CONDITION: 

The  candidate  is  registered  in  the  Reserve  Billet  Advertisement  System  and 
has  been  assigned  the  appropriate  level  of  access. 

TRIGGER: 

The  candidate  clicks  on  “Create  RQS”. 

TYPICAL  COURSE 

OF  EVENTS: 

Actor  Action 

System  Response 

Step  1 :  The  candidate  selects 
“Create  RQS”  from  main  menu. 

Step  2:  The  system  displays  RQS  with 
data  populated  from  RBAS. 

Step  3:  The  candidate  will 
input  his  or  her  information  into 
the  free  form  text  blocks  and 
click  “submit”  when  finished. 

Step  4:  If  data  is  input  correctly,  the 
system  accepts  the  RQS  and  stores  it. 

Step  5:  The  candidate  receives 
confirmation  that  RQS  has 
successfully  been  created. 

Step  6:  The  system  generates  leads  for 
Employers  and  Recruiters  that  have 
subscribed  to  automated  candidate  search 
services. 

Step  7:  The  system  generates  an  email 
for  the  candidate  acknowledging  the 
systems  acceptance  of  their  RQS. 

ALTERNATE 

COURSES: 

CONCLUSION: 

The  candidate  successfully  creates  a  RQS. 

POST-CONDITION: 

User  is  returned  to  portal  homepage. 

BUSINESS  RULES 

The  candidate  will  not  be  able  to  update  any  personal  information  directly, 
with  the  exception  of  resume  remarks  on  RQS. 

IMPLEMENTATION 
CONTRAINTS  AND 
SPECIFICATIONS 

ASSUMPTIONS: 

User  must  have  access  to  NMCI  compliant  web  browser. 
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Candidate  Subsystem 


USE  CASE  NAME: 

Review  Reserve  Qualification 

Summary 

USE  CASE  TYPE 

System  Analysis 

PRIORITY: 

High 

SOURCE: 

Requirements  Analysis 

PRIMARY  BUSINESS 
ACTOR 

Candidate 

PRIMARY  SYSTEM 
ACTOR 

OTHER 

PARTICIPATING 

ACTORS: 

DESCRIPTION: 

This  use  case  describes  how  a  candidate  can  review  their  electronic  Reserve 
Qualification  Summary  (RQS). 

PRE-CONDITION: 

The  candidate  is  registered  in  the  Reserve  Billet  Advertisement  System  and 
has  been  assigned  the  appropriate  level  of  access. 

TRIGGER: 

The  candidate  clicks  on  “Review  RQS”. 

TYPICAL  COURSE 

Actor  Action 

System  Response 

OF  EVENTS: 


Step  1 :  The  candidate  selects 
“Review  RQS”  from  main 
menu. 


Step  3:  The  candidate  reviews 
the  RQS. 


Step  2:  The  system  displays  the 
candidate’s  RQS  with  data  populated 
from  RBAS. 


ALTERNATE 

COURSES: 


CONCLUSION: 


The  candidate  successfully  reviews  their  RQS. 


POST-CONDITION: 


User  is  returned  to  portal  homepage. 


BUSINESS  RULES 


IMPLEMENTATION 
CONTRAINTS  AND 
SPECIFICATIONS 


ASSUMPTIONS: 


User  must  have  access  to  NMCI  compliant  web  browser. 


Review  Resume  Process  Model 


Resume 

Requested 


Review 

Resume 


Query  For 
Form  Values 


Query  Results 


Query  For  Form  Values 
Values  For  RQS 
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Candidate  Subsystem 


USE  CASE  NAME: 

Update  Reserve  Qualification 

Summary 

USE  CASE  TYPE 

System  Analysis 

PRIORITY: 

High 

SOURCE: 

Requirements  Analysis 

PRIMARY  BUSINESS 
ACTOR 

Candidate 

PRIMARY  SYSTEM 
ACTOR 

OTHER 

PARTICIPATING 

ACTORS: 

Employer 

Recruiter 

DESCRIPTION: 

This  use  case  describes  how  a  candidate  can  update  an  electronic  Reserve 
Qualification  Summary  (RQS). 

PRE-CONDITION: 

The  candidate  is  registered  in  the  Reserve  Billet  Advertisement  System  and 
has  been  assigned  the  appropriate  level  of  access. 

TRIGGER: 

The  candidate  clicks  on  “Update  RQS”. 

TYPICAL  COURSE 

OF  EVENTS: 

Actor  Action 

System  Response 

Step  1 :  The  candidate  selects 
“Update  RQS”  from  main 
menu. 

Step  2:  The  system  displays  the 
candidate’s  RQS  with  data  populated 
from  RBAS. 

Step  3:  The  candidate  will 
update  his  or  her  information  in 
the  free  form  text  blocks  and 
click  “submit”  when  finished. 

Step  4:  If  data  is  input  correctly,  the 
system  accepts  the  updated  RQS 
information  and  stores  it. 

Step  5:  The  candidate  receives 
confirmation  that  their  RQS  has 
successfully  been  updated. 

Step  6:  The  system  generates  leads  for 
Employers  and  Recruiters  that  have 
subscribed  to  automated  candidate  search 
services. 

Step  7:  The  system  generates  an  email 
for  the  candidate  acknowledging  the  RQS 
update. 

ALTERNATE 

COURSES: 

CONCLUSION: 

The  candidate  successfully  updates  their  RQS. 

POST-CONDITION: 

User  is  returned  to  portal  homepage. 

BUSINESS  RULES 

The  candidate  will  not  be  able  to  update  any  personal  information  directly, 
with  the  exception  of  resume  remarks  on  RQS. 

IMPLEMENTATION 
CONTRAINTS  AND 
SPECIFICATIONS 

ASSUMPTIONS: 

User  must  have  access  to  NMCI  compliant  web  browser. 
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Update  Resume  Process  Model 


Candidate 


Updates 

Resume 


Acceptance 

Notification 


Update 

Resume 


Query  For 
Konn  Values 


Query  Results 
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Candidate  Subsystem 


USE  CASE  NAME: 

Delete  Reserve  Qualification  Summary 

USE  CASE  TYPE 

System  Analysis 

PRIORITY: 

High 

SOURCE: 

Requirements  Analysis 

PRIMARY  BUSINESS 
ACTOR 

Candidate 

PRIMARY  SYSTEM 
ACTOR 

OTHER 

PARTICIPATING 

ACTORS: 

Employer 

Recruiter 

DESCRIPTION: 

This  use  case  describes  how  a  candidate  can  delete  their  electronic  Reserve 
Qualification  Summary  (RQS). 

PRE-CONDITION: 

The  candidate  is  registered  in  the  Reserve  Billet  Advertisement  System  and 
has  been  assigned  the  appropriate  level  of  access. 

TRIGGER: 

The  candidate  clicks  on  “Delete  RQS”. 

TYPICAL  COURSE 

Actor  Action 

System  Response 

OF  EVENTS: 


Step  1 :  The  candidate  selects 
“Delete  RQS”  from  main  menu. 


Step  3:  The  candidate  clicks 
“Delete  RQS”. 


Step  5:  Candidate  selects  “yes” 
or  “no”. 


Step  2:  The  system  displays  the 
candidate’s  RQS  with  data  populated 
from  RBAS. 


Step  4:  System  prompts  candidate  “Are 
you  sure  you  want  to  delete  this  RQS?” 


Step  6:  If  “yes”  RQS  information  is 
deleted  from  RBAS. 


ALTERNATE 

COURSES: 


CONCLUSION: 


The  candidate  successfully  deletes  their  RQS. 


POST-CONDITION: 


User  is  returned  to  portal  homepage. 


BUSINESS  RULES 


IMPLEMENTATION 
CONTRAINTS  AND 
SPECIFICATIONS 


ASSUMPTIONS: 


User  must  have  access  to  NMCI  compliant  web  browser. 


Delete  Resume  Process  Model 


Delete  Resume  

Candidate 

Acceptance 

Notification 

Delete 

Resume 


Query  Kcir 
Form  Values 


Query  Results 


Candidas 


Query  For  Current  Values 
Values  F  ur  RQS 


Record  Deleted 
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APPENDIX  C.  RECRUITER  USE  CASES 


Recruiter  Subsystem 


USE  CASE  NAME: 

Search  all  available  billets 

USE  CASE  TYPE 

System  Analysis 

PRIORITY: 

Medium 

SOURCE: 

Requirement 

PRIMARY  BUSINESS 
ACTOR 

Recruiter 

PRIMARY  SYSTEM 
ACTOR 

OTHER 

PARTICIPATING 

ACTORS: 

Employer 

DESCRIPTION: 

This  Use  Case  describes  how  a  recruiter  can  search  for  billets  that  match 
their  search  criteria  (MOS,  GeoLoc,  Dates). 

PRE-CONDITION: 

The  PSR  is  registered  in  the  Reserve  Billet  Advertisement  System  and  has 
been  assigned  the  appropriate  level  of  access. 

TRIGGER: 

PSR  conducts  a  search  of  billets. 

TYPICAL  COURSE 

OF  EVENTS: 

Actor  Action 

System  Response 

Step  1 :  PSR  enters  search 
criteria  into  query  form  and 
clicks  “submit”. 

Step  2:  System  verifies  the  data  entered 
into  search  form. 

Step  3:  If  the  information  is  complete, 
the  system  accepts  the  request  and 
conducts  the  search. 

Step  4:  System  displays  matching  billets 
to  the  PSR. 

ALTERNATE 

COURSES: 

SR  Step  3:  System  displays  an  error  screen  if  no  billets  match  and  prompts 
user  to  correct 

AA  Step  4:  PSR  reenters  data,  resubmits  and  the  process  begins  at  step  #2 
of  “typical  course  of  events.” 

OR 

SR  Step  3:  System  displays  an  error  screen  if  information  is  incomplete  and 
prompts  user  to  correct  and  reenter  data. 

AA  Step  4:  PSR  reenters  data,  resubmits  and  the  process  begins  at  step  #2 
of  “typical  course  of  events.” 

CONCLUSION: 

The  PSR  is  presented  with  the  results  of  his  or  her  query. 

POST-CONDITION: 

User  is  returned  to  portal  homepage. 

BUSINESS  RULES 

IMPLEMENTATION 
CONTRAINTS  AND 
SPECIFICATIONS 

ASSUMPTIONS: 

User  must  have  access  to  NMCI  compliant  web  browser. 
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Search  Billets  Process  Model 
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Recruiter  Subsystem 


USE  CASE  NAME: 

Search  all  available  candidates 

USE  CASE  TYPE 

System  Analysis 

PRIORITY: 

Medium 

SOURCE: 

Requirement 

PRIMARY  BUSINESS 
ACTOR 

Recruiter 

PRIMARY  SYSTEM 
ACTOR 

OTHER 

PARTICIPATING 

ACTORS: 

Candidate 

DESCRIPTION: 

This  Use  Case  describes  how  a  recruiter  can  search  for  candidates  that 
match  their  search  criteria  (MOS,  GeoLoc,  Dates). 

PRE-CONDITION: 

The  recruiter  is  registered  in  the  Reserve  Billet  Advertisement  System  and 
has  been  assigned  the  appropriate  level  of  access. 

TRIGGER: 

PSR  conducts  a  search  of  candidates. 

TYPICAL  COURSE 

OF  EVENTS: 

Actor  Action 

System  Response 

Step  1 :  Recruiter  enters  search 
criteria  into  query  form  and 
clicks  “submit”. 

Step  2:  System  verifies  the  data  entered 
into  search  form. 

Step  3:  If  the  information  is  complete, 
the  system  accepts  the  request  and 
conducts  the  search. 

Step  4:  System  displays  matching 
candidates  to  the  recruiter. 

ALTERNATE 

COURSES: 

SR  Step  3:  System  displays  an  error  screen  if  no  candidates  match  and 
prompts  user  to  correct 

AA  Step  4:  Recruiter  reenters  data,  resubmits  and  the  process  begins  at  step 
#2  of  “typical  course  of  events.” 

OR 

SR  Step  3:  System  displays  an  error  screen  if  information  is  incomplete  and 
prompts  user  to  correct  and  reenter  data. 

AA  Step  4:  PSR  reenters  data,  resubmits  and  the  process  begins  at  step  #2 
of  “typical  course  of  events.” 

CONCLUSION: 

The  PSR  is  presented  with  the  results  of  his  or  her  query. 

POST-CONDITION: 

User  is  returned  to  portal  homepage. 

BUSINESS  RULES 

IMPLEMENTATION 
CONTRAINTS  AND 
SPECIFICATIONS 

ASSUMPTIONS: 

User  must  have  access  to  NMCI  compliant  web  browser. 
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Recruiter  Subsystem 


USE  CASE  NAME: 

Manage  candidate  leads 

USE  CASE  TYPE 

System  Analysis 

PRIORITY: 

Medium 

SOURCE: 

Requirement 

PRIMARY  BUSINESS 
ACTOR: 

Recruiter 

OTHER 

PARTICIPATING 

ACTORS: 

Candidate 

OTHER 

INTERESTED 

STAKEHOLDERS: 

DESCRIPTION: 

This  Use  Case  describes  how  a  Recruiter  can  manage  all  leads  that  have 
been  generated  for  billets  that  are  included  in  their  district. 

PRE-CONDITION: 

You  must  have  the  proper  roles  to  be  able  to  complete  this  use-case. 

TRIGGER: 

This  use  case  is  initiated  when  a  recruiter  with  roles  clicks  “Manage  Leads” 

TYPICAL  COURSE 

OF  EVENTS: 

Actor  Action 

System  Response 

Step  1 :  Recruiter  with  roles 
clicks  “Manage  Leads” 

Step  2:  Screen  with  listing  of  all  current 
leads  appears  for  the  recruiter  to  select 
which  one  to  manage. 

Step  3 :  Recruiter  clicks  on 
appropriate  lead  to  obtain  all  its 
details. 

Step  4:  System  displays  all  details  of 
specific  lead. 

Step  5 :  Recruiter  is  given  the 
option  to  update/delete  the  lead 
or  return  to  the  Leads  menu. 

ALTERNATE 

COURSES: 

CONCLUSION: 

This  use  case  concludes  when  the  recruiter  is  successfully  able  to  manage 
candidate  leads. 

POST-CONDITION: 

User  is  returned  to  portal  homepage. 

BUSINESS  RULES 

IMPLEMENTATION 
CONTRAINTS  AND 
SPECIFICATIONS 

ASSUMPTIONS: 

User  must  have  access  to  NMCI  compliant  web  browser. 

Recruiter  Manage  Leads  Process  Model 
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Recruiter  Subsystem 


USE  CASE  NAME: 

View  Ad  Hoc  Report 

USE  CASE  TYPE 

System  Analysis 

PRIORITY: 

Medium 

SOURCE: 

Requirement 

PRIMARY  BUSINESS 
ACTOR 

Recruiter 

PRIMARY  SYSTEM 
ACTOR 

OTHER 

PARTICIPATING 

ACTORS: 

DESCRIPTION: 

This  Use  Case  describes  how  a  Recruiter  generates  and  views  ad  hoc 
reports. 

PRE-CONDITION: 

The  recruiter  is  registered  in  the  Reserve  Billet  Advertisement  System  and 
has  been  assigned  the  appropriate  level  of  access 

TRIGGER: 

Recruiter  inputs  query  data  into  the  report  input  form  and  hits  submit. 

TYPICAL  COURSE 

OF  EVENTS: 

Actor  Action 

System  Response 

Step  1 :  The  recruiter  enters  the 
requested  dataset  into  the  form 
and  clicks  the  “submit”  button. 

Step  2:  System  verifies  completeness  of 
data  entered  into  query. 

Step  3:  If  all  required  information  is 
entered,  the  system  performs  the  query. 

Step  4:  System  displays  results  to 
recruiter. 

ALTERNATE 

COURSES: 

SR  Step  3:  All  the  required  information  not  present,  error  message  sent  to 
user. 

AA  Step  4:  The  recruiter  corrects  the  error  and  resubmits. 

SR  Step  5:  System  verifies  completeness  of  data  entered  into  query. 

SR  Step  6:  If  all  required  information  is  entered,  the  system  performs  the 
query. 

SR  Step  7:  System  displays  results  to  recruiter. 

CONCLUSION: 

The  recruiter  is  presented  with  report  requested. 

POST-CONDITION: 

User  is  returned  to  portal  homepage. 

BUSINESS  RULES 

IMPLEMENTATION 
CONTRAINTS  AND 
SPECIFICATIONS 

ASSUMPTIONS: 

User  must  have  access  to  NMCI  compliant  web  browser. 
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Recruiter  Subsystem 


USE  CASE  NAME: 

View  Vacant  Billet  Report 

USE  CASE  TYPE 

System  Analysis 

PRIORITY: 

Low 

SOURCE: 

Requirement 

PRIMARY  BUSINESS 
ACTOR 

Recruiter 

PRIMARY  SYSTEM 
ACTOR 

OTHER 

PARTICIPATING 

ACTORS: 

DESCRIPTION: 

This  Use  Case  describes  how  a  Recruiter  generates  and  views  the  vacant 
billet  report. 

PRE-CONDITION: 

The  recruiter  is  registered  in  the  Reserve  Billet  Advertisement  System  and 
has  been  assigned  the  appropriate  level  of  access 

TRIGGER: 

Recruiter  enters  reports  page  and  clicks  on  vacant  billet  report. 

TYPICAL  COURSE 

Actor  Action 

System  Response 

OF  EVENTS: 


Step  1 :  The  recruiter  enters  the 
reports  page  and  clicks  on 
vacant  billet  report.  (Recruiter 
will  have  option  to  filter 
results) 


Step  2:  System  queries  all  current 
advertisements  which  are  currently 
vacant. 


Step  3:  System  displays  results  to 
recruiter. 


ALTERNATE 

COURSES: 


CONCLUSION: 


The  recruiter  is  presented  with  report  requested. 


POST-CONDITION: 


User  is  returned  to  portal  homepage. 


BUSINESS  RULES 


IMPLEMENTATION 
CONTRAINTS  AND 
SPECIFICATIONS 


ASSUMPTIONS: 


User  must  have  access  to  NMCI  compliant  web  browser. 
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Recruiter  Subsystem 


USE  CASE  NAME: 

Create  Personal  Web  Portal  Content 

USE  CASE  TYPE 

System  Analysis 

PRIORITY: 

Medium 

SOURCE: 

Requirements  Analysis 

PRIMARY  BUSINESS 
ACTOR 

Recruiter 

PRIMARY  SYSTEM 
ACTOR 

OTHER 

PARTICIPATING 

ACTORS: 

DESCRIPTION: 

This  use  case  describes  how  a  Recruiter  can  create  a  personalized  web  portal 
upon  initial  login  to  the  Reserve  Billet  Advertisement  System. 

PRE-CONDITION: 

The  recruiter  is  registered  in  the  Reserve  Billet  Advertisement  System  and 
has  been  assigned  the  appropriate  level  of  access. 

TRIGGER: 

The  recruiter  subscribes  to  service  via  RBAS. 

TYPICAL  COURSE 

OF  EVENTS: 

Actor  Action 

System  Response 

Step  1 :  The  recruiter  logs  on  to 
RBAS  for  the  first  time. 

Step  2:  The  system  prompts  the  recruiter 
to  select  what  content  they  want  to  add  to 
their  personal  portal.  The  user  will  be 
provided  with  a  list  of  alternatives  to 
select  from. 

Step  3:  The  recruiter  selects  the 
services  that  he  or  she  wants  to 
populate  their  personal  portal 
with.  When  the  recruiter  is  done 
choosing,  he  or  she  hits 
“submit”  to  transmit  settings 
back  to  RBAS. 

Step  4:  RBAS  acknowledges  the  request, 
and  updates  the  recruiter’s  preferences 
queue  and  updates  the  database. 

Step  5:  The  system  sends  a  positive 
response  acknowledging  changes  and 
instructs  user  to  log  off  and  back  on  to 
view  the  changes. 

ALTERNATE 

COURSES: 

None 

CONCLUSION: 

The  recruiter  personalizes  their  web  portal. 

POST-CONDITION: 

User  is  returned  to  portal  homepage. 

BUSINESS  RULES 

IMPLEMENTATION 
CONTRAINTS  AND 
SPECIFICATIONS 

ASSUMPTIONS: 

User  must  have  access  to  NMCI  compliant  web  browser. 
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Recruiter  Subsystem 


USE  CASE  NAME: 

Review  Personal  Web  Portal  Content 

USE  CASE  TYPE 

System  Analysis 

PRIORITY: 

Medium 

SOURCE: 

Requirements  Analysis 

PRIMARY  BUSINESS 
ACTOR 

Recruiter 

PRIMARY  SYSTEM 
ACTOR 

OTHER 

PARTICIPATING 

ACTORS: 

DESCRIPTION: 

This  use  case  describes  how  a  recruiter  can  review  the  customizable 
information  contained  within  their  personal  web  portal  (ie  RSS  feeds, 
content) 

PRE-CONDITION: 

The  recruiter  is  registered  in  the  Reserve  Billet  Advertisement  System  and 
has  been  assigned  the  appropriate  level  of  access. 

TRIGGER: 

The  recruiter  reviews  their  personal  settings  within  their  RBAS  personal 
portal. 

TYPICAL  COURSE 

OF  EVENTS: 

Actor  Action 

System  Response 

Step  1 :  The  recruiter  selects 
“review”  portal  settings  from 
menu  of  choices. 

Step  2:  The  system  queries  the  database 
for  the  recruiter’s  currents  settings. 

Step  3:  If  the  recruiter  has  personal 
settings,  RBAS  displays  the  queries 
results. 

ALTERNATE 

COURSES: 

None 

CONCLUSION: 

The  recruiter  reviews  their  personal  web  portal  settings. 

POST-CONDITION: 

User  is  returned  to  portal  homepage. 

BUSINESS  RULES 

IMPLEMENTATION 
CONTRAINTS  AND 
SPECIFICATIONS 

ASSUMPTIONS: 

User  must  have  access  to  NMCI  compliant  web  browser. 
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Recruiter  Subsystem 


USE  CASE  NAME: 

Update  Personal  Web  Portal  Content 

USE  CASE  TYPE 

System  Analysis 

PRIORITY: 

Medium 

SOURCE: 

Requirements  Analysis 

PRIMARY  BUSINESS 
ACTOR 

Recruiter 

PRIMARY  SYSTEM 
ACTOR 

OTHER 

PARTICIPATING 

ACTORS: 

DESCRIPTION: 

This  use  case  describes  how  a  recruiter  can  update  the  customizable 
information  contained  within  their  personal  web  portal  (ie  RSS  feeds, 
content) 

PRE-CONDITION: 

The  recruiter  is  registered  Reserve  Billet  Advertisement  System  and  has 
been  assigned  the  appropriate  level  of  access. 

TRIGGER: 

The  recruiter  updates  their  personal  settings  within  their  RBAS  personal 
portal. 

TYPICAL  COURSE 

OF  EVENTS: 

Actor  Action 

System  Response 

Step  1 :  The  recruiter  selects 
“update”  portal  settings  from 
menu  of  choices. 

Step  2:  The  system  queries  the  database, 
populates  the  list  of  alternatives  with 
current  settings. 

Step  3 :  The  system  prompts  the  recruiter 
to  update  their  selections. 

Step  4:  The  recruiter  selects  the 
services  that  he  or  she  wants  to 
populate  their  personal  portal 
with.  When  the  recruiter  is  done 
modifying  their  settings  he  or 
she  hits  “submit”  to  transmit 
settings  back  to  RBAS. 

Step  5:  RBAS  acknowledges  the  request, 
and  updates  the  recruiter’s  preferences 
queue  and  updates  the  database. 

Step  6:  The  system  sends  a  positive 
response  acknowledging  the  changes  and 
instructs  user  to  log  off  and  back  on  to 
view  the  changes. 

ALTERNATE 

COURSES: 

None 

CONCLUSION: 

The  recruiter  updates  their  personal  web  portal  settings. 

POST-CONDITION: 

User  is  returned  to  portal  homepage. 

BUSINESS  RULES 

IMPLEMENTATION 
CONTRAINTS  AND 
SPECIFICATIONS 

ASSUMPTIONS: 

User  must  have  access  to  NMCI  compliant  web  browser. 
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Update  Recruiter  Portal  Settings  Process  Model 

Query  To 


.'Assigns  Portal 
Settings 

f  >| 

Populate  Form 

Values  

Recruiter 

- ► 

Acceptance 

Update  Web 
Portal 

- ^ 

Query  Results 

Rcrruner 

Notification 

Update  Recruiter 

Settings 

Content 

Preferences 

Query  For  Form  Values 


Values  For  Autopnpulatc  Form 


Portal  Sellings 


170 


Recruiter  Subsystem 


USE  CASE  NAME: 

Delete  Personal  Web  Portal  Content 

USE  CASE  TYPE 

System  Analysis 

PRIORITY: 

Medium 

SOURCE: 

Requirements  Analysis 

PRIMARY  BUSINESS 
ACTOR 

Recruiter 

PRIMARY  SYSTEM 
ACTOR 

OTHER 

PARTICIPATING 

ACTORS: 

DESCRIPTION: 

This  use  case  describes  how  a  recruiter  can  delete  the  customizable 
information  contained  within  their  personal  web  portal  (ie  RSS  feeds, 
content) 

PRE-CONDITION: 

The  recruiter  is  registered  in  the  Reserve  Billet  Advertisement  System  and 
has  been  assigned  the  appropriate  level  of  access. 

TRIGGER: 

The  recruiter  deletes  their  personal  settings  within  their  RBAS  personal 
portal. 

TYPICAL  COURSE 

Actor  Action 

System  Response 

OF  EVENTS: 


Step  1  :  The  recruiter  selects 
“delete”  portal  settings  from 
menu  of  choices. 


Step  4:  The  recruiter 
acknowledges  the  system 
prompt. 


Step  2:  The  system  queries  the  database 
for  the  recruiter’s  currents  settings. 


Step  3 :  If  the  recruiter  has  personal 
settings,  RBAS  displays  the  query  results 
and  prompts  the  user  to  verify  that  they 
want  to  delete  these  settings. _ 

Step  5:  The  system  deletes  the  recruiter’s 
personal  settings  and  restores  the 
system’s  default  settings. 


ALTERNATE 

COURSES: 


SR  Step  3  :  The  recruiter  does 
displays  an  error  message  and 


not  have  any  portal  settings  and  the  system 
the  transaction  is  canceled. 


CONCLUSION: 


The  recruiter  deletes  their  personal  web  portal  settings. 


POST-CONDITION: 


User  is  returned  to  portal  homepage. 


BUSINESS  RULES 


IMPLEMENTATION 
CONTRAINTS  AND 
SPECIFICATIONS 


ASSUMPTIONS: 


User  must  have  access  to  NMCI  compliant  web  browser. 


Delete  Recruiter  Portal  Settings  Process  Model 


Del«e 


171 


Recruiter  Subsystem 


USE  CASE  NAME: 

Create  Candidate  Lead  Subscription 

USE  CASE  TYPE 

System  Analysis 

PRIORITY: 

Medium 

SOURCE: 

Requirements  Analysis 

PRIMARY  BUSINESS 
ACTOR: 

Recruiter 

OTHER 

PARTICIPATING 

ACTORS: 

Candidate 

DESCRIPTION: 

This  Use  Case  describes  how  a  Recruiter  can  create  a  subscription  to 
automatically  receive  updates  (email  or  notification  on  portal)  if  new 
candidates  that  fit  his  or  her  criteria  (geo  loc,  dates,  MOS)  have  recently 
registered,  posted  new  or  updated  information  or  deleted  items  from  their 
profile. 

PRE-CONDITION: 

The  recruiter  is  registered  in  the  Reserve  Billet  Advertisement  System  and 
has  been  assigned  the  appropriate  level  of  access. 

TRIGGER: 

This  use  case  is  initiated  when  a  recruiter  with  roles  clicks  “Create 
Subscription” 

TYPICAL  COURSE 

OF  EVENTS: 

Actor  Action 

System  Response 

Step  1 :  Recruiter  with  roles 
clicks  “Create  Subscription” 

Step  2:  Screen  with  subscription  criteria 
(MOS,  GeoLoc,  Dates)  appears  for 
recruiter  to  select  or  input. 

Step  3 :  Recruiter  completes 
form  and  clicks  submit. 

Step  4:  The  system  verifies  the 
information. 

Step  5:  If  the  information  is  correct,  the 
system  accepts  the  subscription. 

Step  6:  The  system  places  the  recruiter 
and  their  search  criteria  in  its 
subscription  queue. 

Step  7:  Leads  are  generated  for 
candidates  that  have  subscribed  to 
recruiter  search  services. 

Step  8:  The  system  compares  the  criteria 
of  newly  posted,  updated  or  deleted 
candidates  versus  the  criteria  posted  by 
subscribers. 

ALTERNATE 

COURSES: 

CONCLUSION: 

This  use  case  concludes  when  the  recruiter  receives  a  confirmation  that  the 
subscription  has  been  created  successfully. 

POST-CONDITION: 

User  is  returned  to  portal  homepage. 

BUSINESS  RULES 

IMPLEMENTATION 
CONTRAINTS  AND 
SPECIFICATIONS 

ASSUMPTIONS: 

User  must  have  access  to  NMCI  compliant  web  browser. 
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Recruiter  Create  Subscription  Process  Model 
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Recruiter  Subsystem 


USE  CASE  NAME: 

Review  Candidate  Lead  Subscription 

USE  CASE  TYPE 

System  Analysis 

PRIORITY: 

Medium 

SOURCE: 

Requirements  Analysis 

PRIMARY  BUSINESS 
ACTOR: 

Recruiter 

OTHER 

PARTICIPATING 

ACTORS: 

DESCRIPTION: 

This  Use  Case  describes  how  a  recruiter  can  review  their  subscriptions 
without  making  any  modifications  to  them. 

PRE-CONDITION: 

Recruiter  must  have  the  proper  roles  to  be  able  to  complete  this  use-case. 

TRIGGER: 

This  use  case  is  initiated  when  a  Recruiter  with  roles  clicks  “Review 
Subscriptions” 

TYPICAL  COURSE 

OF  EVENTS: 

Actor  Action 

System  Response 

Step  1 :  Recruiter  with  roles 
clicks  “Review  Subscriptions” 

Step  2:  The  system  will  query  the 
database  to  retrieve  the  recruiter’s 
subscription  information. 

Step  3:  Once  an  active  record  is  found, 
the  system  will  display  the  retrieved 
subscription  information. 

Step  4:  Recruiter  can  review 
subscription  information 

ALTERNATE 

COURSES: 

SR  Step  3:  The  system  is  unable  to  locate  a  subscription  for  the  recruiter. 

SR  Step  4:  The  system  displays  an  error  message  that  informs  the  recruiter 
that  he  or  she  has  no  active  subscriptions. 

CONCLUSION: 

This  use  case  concludes  when  the  recruiter  can  review  their  current 
subscription(s). 

POST-CONDITION: 

User  is  returned  to  portal  homepage. 

BUSINESS  RULES 

IMPLEMENTATION 
CONTRAINTS  AND 
SPECIFICATIONS 

ASSUMPTIONS: 

User  must  have  access  to  NMCI  compliant  web  browser. 
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Recruiter  Subsystem 


USE  CASE  NAME: 

Update  Candidate  Lead  Subscription 

USE  CASE  TYPE 

PRIORITY: 

Medium 

System  Analysis 

SOURCE: 

Requirements  Analysis 

PRIMARY  BUSINESS 
ACTOR: 

Recruiter 

OTHER 

PARTICIPATING 

ACTORS: 

Candidate 

DESCRIPTION: 

This  Use  Case  describes  how  a  recruiter  can  update  their  active 
subscriptions. 

PRE-CONDITION: 

Recruiter  must  have  the  proper  roles  to  be  able  to  complete  this  use-case. 

TRIGGER: 

This  use  case  is  initiated  when  a  Recruiter  with  roles  clicks  “Update 
Subscription” 

TYPICAL  COURSE 

Actor  Action 

System  Response 

OF  EVENTS: 

Step  1 :  Recruiter  with  roles 
clicks  “Update  Subscriptions” 

Step  2:  The  system  will  query  the 
database  to  retrieve  the  recruiter’s 
subscription  information. 

Step  3:  Once  an  active  record  is  found, 
the  system  will  prompt  the  recruiter  to 
verify  if  the  information  retrieved  is  the 
subscription  they  want  to  update. 

Step  4:  The  recruiter  verifies 
the  information  and 
acknowledges  by  pressing 
continue. 

Step  5:  The  system  then  opens  a 
subscription  edit  window  and  populates 
the  fields  with  the  retrieved  information 
and  prompts  the  user  to  update  the 
subscription. 

Step  6:  The  recruiter  updates 
the  information  and  hits 
“submit”  when  complete. 

Step  7:  The  system  error  checks  the 
information,  if  the  information  is  correct 
the  update  is  accepted,  acknowledged 
and  the  database  is  updated. 

Step  8:  The  system  places  the  recruiter 
and  their  search  criteria  in  its 
subscription  queue. 

Step  9:  Leads  are  generated  for 
candidates  that  have  subscribed  to 
recruiter  search  services. 

Step  10:  The  system  compares  the  billet 
identifiers  of  newly  posted,  updated  or 
deleted  jobs  versus  the  criteria  posted  by 
subscribers. 

Step  11:  If  the  search  criteria  matches,  an 
email  is  generated  and  sent  to  the 
recruiter  or  his  portal  is  updated,  (which 
ever  method  is  selected) 

ALTERNATE 

COURSES: 

SR  Step  3:  The  system  is  unable  to  locate  a  subscription  for  the  recruiter. 

SR  Step  4:  The  system  displays  an  error  message  that  informs  the  recruiter 
that  he  or  she  has  no  active  subscriptions. 

CONCLUSION: 

This  use  case  concludes  when  the  recruiter  can  update  their  current 
subscription(s). 
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POST-CONDITION: 

User  is  returned  to  portal  homepage. 

BUSINESS  RULES 

IMPLEMENTATION 
CONTRAINTS  AND 
SPECIFICATIONS 

ASSUMPTIONS: 

User  must  have  access  to  NMCI  compliant  web  browser. 

Recruiter  Update  Subscription  Process  Model 
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Recruiter  Subsystem 


USE  CASE  NAME: 

Delete  Candidate  Lead  Subscription 

USE  CASE  TYPE 

System  Analysis 

PRIORITY: 

Medium 

SOURCE: 

Requirements  Analysis 

PRIMARY  BUSINESS 
ACTOR: 

Reservist 

OTHER 

PARTICIPATING 

ACTORS: 

Candidate 

DESCRIPTION: 

This  Use  Case  describes  how  a  Recruiter  can  delete  an  active  subscription. 

PRE-CONDITION: 

You  must  have  the  proper  roles  to  be  able  to  complete  this  use-case. 

TRIGGER: 

This  use  case  is  initiated  when  a  Recruiter  with  roles  clicks  “Delete 
Subscription” 

TYPICAL  COURSE 

OF  EVENTS: 

Actor  Action 

System  Response 

Step  1 :  The  recruiter  selects 
“delete”  subscription  from 
menu  of  choices. 

Step  2:  The  system  will  query  the 
database  to  retrieve  the  recruiter’s 
subscription  information. 

Step  3:  Once  an  active  record  is  found, 
the  system  will  prompt  the  recruiter  to 
verify  if  the  information  retrieved  is  the 
subscription  they  want  deleted. 

Step  4:  The  recruiter  verifies 
the  information  and 
acknowledges  by  pressing 
continue. 

Step  5:  The  system  then  prompts  the 
recruiter  if  they  are  certain  they  want  to 
cancel  this  subscription. 

Step  6:  The  recruiter 
acknowledges  his  or  her 
approval  by  clicking  “yes” 

Step  7:  The  system  receives  the  response 
and  deletes  the  subscription  from  the 
database 

Step  8:  A  success  message  is  generated 
and  displayed  to  the  recruiter. 

ALTERNATE 

COURSES: 

SR  Step  3:  The  system  is  unable  to  locate  a  subscription  for  the  recruiter. 

SR  Step  4:  The  system  displays  an  error  message  that  informs  the  recruiter 
that  he  or  she  has  no  active  subscriptions. 

AA  Step  6:  The  recruiter  declines  to  delete  subscription. 

SR  Step  7:  The  system  acknowledges  the  negative  response  and  deletes  the 
transaction. 

SR  Step  8:  The  system  displays  successful  cancellation  message  to  user. 

CONCLUSION: 

This  use  case  concludes  when  the  recruiter  receives  a  confirmation  that  the 
subscription  was  successfully  deleted. 

POST-CONDITION: 

User  is  returned  to  portal  homepage. 

BUSINESS  RULES 

IMPLEMENTATION 
CONTRAINTS  AND 
SPECIFICATIONS 

ASSUMPTIONS: 

User  must  have  access  to  NMCI  compliant  web  browser. 
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Recruiter  Delete  Subscription  Process  Model 
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Recruiter  Subsystem 


USE  CASE  NAME: 

Facilitate  Community  Events 

USE  CASE  TYPE 

System  Analysis 

PRIORITY: 

Medium 

SOURCE: 

Requirements  Analysis 

PRIMARY  BUSINESS 
ACTOR: 

Recruiter 

OTHER 

PARTICIPATING 

ACTORS: 

Candidate 

Employer 

DESCRIPTION: 

This  use  case  describes  how  a  recruiter  manages  the  forum  and  blog 
contents  within  their  recruiting  district. 

PRE-CONDITION: 

You  must  have  the  proper  roles  to  be  able  to  complete  this  use-case. 

TRIGGER: 

This  use  case  is  initiated  when  a  recruiter  with  roles  clicks  “Facilitate 
Community  Events” 

TYPICAL  COURSE 

OF  EVENTS: 

Actor  Action 

System  Response 

Step  1 :  Recruiter  with  roles 
clicks  “Facilitate  Community 
Events” 

Step  2:  Screen  with  forum  and  blog 
menus  is  displayed. 

Step  3 :  Recruiter  clicks  on 
forum  or  blog  to  add/edit  items. 

ALTERNATE 

COURSES: 

CONCLUSION: 

This  use  case  concludes  when  the  recruiter  receives  a  confirmation  that  the 
forum/blog  was  successfully  updated. 

POST-CONDITION: 

User  is  returned  to  portal  homepage. 

BUSINESS  RULES 

IMPLEMENTATION 
CONTRAINTS  AND 
SPECIFICATIONS 

ASSUMPTIONS: 

User  must  have  access  to  NMCI  compliant  web  browser. 
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APPENDIX  D.  MANAGER  USE  CASES 


Management  Subsystem 


USE  CASE  NAME: 

Create  Roles  For  Users  or  Groups  of 
RBAS 

USE  CASE  TYPE 

System  Analysis 

PRIORITY: 

High 

SOURCE: 

System  Requirement 

PRIMARY  BUSINESS 
ACTOR 

System  Manager 

PRIMARY  SYSTEM 
ACTOR 

OTHER 

PARTICIPATING 

ACTORS: 

Employer 

Recruiter 

Candidate 

DESCRIPTION: 

This  Use  Case  describes  how  system  managers  control  the  access  and 
privileges  of  system  users  by  creating  individual  and  group  accounts. 

PRE-CONDITION: 

The  System  Manager  is  registered  in  the  Reserve  Billet  Advertisement 

System  and  has  been  assigned  the  appropriate  level  of  access. 

TRIGGER: 

The  Use  Case  is  initiated  when  the  System  Manager  creates  a  new  user. 

TYPICAL  COURSE 

OF  EVENTS: 

Actor  Action 

System  Response 

Step  1 :  The  System  Manager 
role  request  queue  has  pending 
requests.  System  Manager 
selects  “Assign  Roles”  from  the 
management  portal. 

Step  2:  The  system  auto  populates  a  user 
input  form  with  the  values  in  RBAS  and 
prompts  the  System  Administrator  to 
assign  the  user  or  groups  roles  and  rights. 

Step  3:  The  System  Manager 
selects  the  appropriate  roles  and 
responsibilities  and  submits 
them  to  RBAS. 

Step  4:  The  system  verifies  the 
information  inputted  into  the  form. 

Step  5:  The  system  accepts  the  new  roles 
assignment  and  stores  it  in  the  database. 

Step  6:  The  system  generates  an  email 
and  broadcast  for  the  user  who  was 
granted  rights  to  the  system,  which 
includes  all  of  their  logon  information 
and  access  privileges. 

Step  7:  The  system  generates  a  success 
message  for  the  System  Manager  and 
prompts  the  user  to  add  another  group  or 
user. 

Step  8:  The  user  responds 
either  negatively  or  positively 
to  the  prompt.  If  positive  the 
process  starts  over  at  Step  1 
else  the  system  exits  the 
application. 
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ALTERNATE 

COURSES: 

SR  Step  3:  All  the  required  information  not  present,  error  message  sent  to 
user. 

AA  Step  4:  System  Manager  corrects  the  error  and  resubmits. 

Return  to  step  2  of  the  “Typical  Course  of  Events” 

OR 

AA  Step  5:  The  System  Manager  responds  negatively  to  system  prompt  and 
request  is  canceled. 

CONCLUSION: 

A  new  group  or  user  is  created. 

POST-CONDITION: 

BUSINESS  RULES 

IMPLEMENTATION 
CONTRAINTS  AND 
SPECIFICATIONS 
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Management  Subsystem 


USE  CASE  NAME: 

Review  Roles  For  Users  or  Groups  of 
RBAS 

USE  CASE  TYPE 

System  Analysis 

PRIORITY: 

High 

SOURCE: 

System  Requirement 

PRIMARY  BUSINESS 
ACTOR 

System  Manager 

PRIMARY  SYSTEM 
ACTOR 

OTHER 

PARTICIPATING 

ACTORS: 

DESCRIPTION: 

This  Use  Case  describes  how  a  System  Manager  can  review  the  roles  and 
rights  assigned  roles  to  a  user  or  a  group. 

PRE-CONDITION: 

The  System  Manager  is  registered  in  the  Reserve  Billet  Advertisement 

System  and  has  been  assigned  the  appropriate  level  of  access. 

TRIGGER: 

The  Use  Case  is  initiated  when  the  System  Manager  chooses  to  review  user 
or  group’s  rights  and  responsibilities. 

TYPICAL  COURSE 

OF  EVENTS: 

Actor  Action 

System  Response 

Step  1 :  The  System  Manager 
selects  a  user  or  group  and  then 
selects  “review  privileges” 
from  the  management  portal. 

Step  2:  The  system  auto  populates  a 
user/group  report  with  the  current  roles 
and  rights  value  and  then  ask  the  user  if 
he  or  she  wishes  to  view  another. 

Step  3:  The  System  Manager 
views  the  data,  and  either 
positively  or  negatively 
responds  to  the  prompt  by 
selecting  “yes”  or  “no”.  If  the 
System  Manager  selects  yes  the 
process  begins  over  at  Step  1 
else  the  system  exits  to  the 
homepage. 

ALTERNATE 

COURSES: 

SR  Step  3:  All  the  required  information  not  present,  error  message  sent  to 
user. 

AA  Step  4:  System  Manager  corrects  the  error  and  resubmits. 

Return  to  step  2  of  the  “Typical  Course  of  Events” 

OR 

AA  Step  5:  The  System  Manager  responds  negatively  to  system  prompt  and 
request  is  canceled. 

CONCLUSION: 

The  System  Manager  views  the  roles  and  rights  of  a  group  or  user. 

POST-CONDITION: 

BUSINESS  RULES 

IMPLEMENTATION 
CONTRAINTS  AND 
SPECIFICATIONS 

ASSUMPTIONS: 
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Review  Role  Process  Model 
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Management  Subsystem 


USE  CASE  NAME: 

Update  User  or  Group  Roles  and 

Rights 

USE  CASE  TYPE 

PRIORITY: 

High 

System  Analysis 

SOURCE: 

System  Requirement 

PRIMARY  BUSINESS 
ACTOR 

System  Manager 

PRIMARY  SYSTEM 
ACTOR 

OTHER 

PARTICIPATING 

ACTORS: 

Employer 

Recruiter 

Candidate 

DESCRIPTION: 

This  Use  Case  describes  how  a  System  Manager  can  update  the  roles  and 
rights  assigned  roles  to  a  user  or  a  group. 

PRE-CONDITION: 

The  System  Manager  is  registered  in  the  Reserve  Billet  Advertisement 

System  and  has  been  assigned  the  appropriate  level  of  access. 

TRIGGER: 

The  Use  Case  is  initiated  when  the  System  Manager  chooses  to  update  a 
user  or  group’s  rights  and  responsibilities. 

TYPICAL  COURSE 

Actor  Action 

System  Response 

OF  EVENTS: 

Step  1 :  The  System  Manager 
selects  a  user  or  group  and  then 
selects  “update  privileges”  from 
the  management  portal. 

Step  2:  The  system  auto  populates  a  user 
or  group  edit  form  with  the  values  stored 
in  the  database  and  prompts  the  System 
Administrator  to  make  any  changes  the 
user  or  groups  roles  and  rights  that  they 
desired. 

Step  3 :  The  System  Manager 
selects  the  appropriate  roles  and 
responsibilities  and  submits 
them  to  RBAS. 

Step  4:  The  system  verifies  the 
information  inputted  into  the  form. 

Step  5:  The  system  accepts  the  changes 
and  stores  it  in  the  database. 

Step  6:  The  system  generates  an  email 
and  broadcast  for  the  user  which  includes 
all  the  changes  that  were  made  to  the 
account. 

Step  7:  The  system  generates  a  success 
message  for  the  System  Administrator 
and  asks  the  user  if  he  or  she  wish  to  edit 
another  group  or  user. 

Step  8:  The  user  responds 
either  negatively  or  positively 
to  the  prompt.  If  positive  the 
process  starts  over  at  Step  1 
else  the  system  exits  the 
application. 

ALTERNATE 

COURSES: 

SR  Step  3:  All  the  required  information  not  present,  error  message  sent  to 
user. 

AA  Step  4:  System  Manager  corrects  the  error  and  resubmits. 

Return  to  step  2  of  the  “Typical  Course  of  Events” 

OR 

AA  Step  5:  The  System  Manager  responds  negatively  to  system  prompt  and 
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request  is  canceled. 

CONCLUSION: 

The  System  Manager  makes  the  desired  changes  to  the  roles  and  rights  of  a 
group  or  user. 

POST-CONDITION: 

BUSINESS  RULES 

IMPLEMENTATION 
CONTRAINTS  AND 
SPECIFICATIONS 

ASSUMPTIONS: 

Update  Role  Process  Model 
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Management  Subsystem 


USE  CASE  NAME: 

Delete  User  or  Group  Roles  and  Rights 

USE  CASE  TYPE 

System  Analysis 

PRIORITY: 

High 

SOURCE: 

Requirement  Analysis 

PRIMARY  BUSINESS 
ACTOR 

System  Manager 

PRIMARY  SYSTEM 
ACTOR 

OTHER 

PARTICIPATING 

ACTORS: 

Candidate 

Employer 

Recruiter 

DESCRIPTION: 

This  Use  Case  describes  how  a  System  Manager  deletes  a  user  access  to  the 
system. 

PRE-CONDITION: 

The  System  Manager  is  registered  in  the  Reserve  Billet  Advertisement 

System  and  has  been  assigned  the  appropriate  level  of  access. 

TRIGGER: 

The  System  Manager  selects  a  user  or  group  whose  rights  they  want  to 
delete. 

TYPICAL  COURSE 

OF  EVENTS: 

Actor  Action 

System  Response 

Step  1 :  The  actor  selects  a  user 
or  group  whose  rights  are  going 
to  be  deleted  and  then  selects 
“delete  user”  from  the 
management  portal. 

Step  2:  The  system  queries  the  database 
and  auto  populates  a  delete  user  input 
form  and  prompts  the  System 
Administrator  to  verify  that  they  want  to 
remove  this  user  or  group  from  the 
system. 

Step  3:  The  user  responds 
either  negatively  or  positively 
to  the  prompt  by  clicking  on 
“yes”  or  “no”. 

Step  3:  If  the  System  Manager  positively 
responds  then  the  system  will  honor  the 
delete  request  of  the  user  or  group  and 
update  the  database. 

Step  4:  The  system  generates  a  success 
message  for  the  System  Administrator. 

Step  6:  The  system  generates  an  email  to 
the  user  and/or  group  and  informs  them 
of  their  privileges  being  revoked. 

ALTERNATE 

COURSES: 

Step  3 :  If  the  System  Manager  negatively  responds  to  the  acknowledgement 
prompt  the  transaction  will  be  cancelled. 

CONCLUSION: 

The  user  and/or  group  rights  were  revoked. 

POST-CONDITION: 

BUSINESS  RULES 

IMPLEMENTATION 
CONTRAINTS  AND 
SPECIFICATIONS 

ASSUMPTIONS: 
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Management  Subsystem 


USE  CASE  NAME: 

Create  Personal  Content  for 

Management  and  Site  Portals 

USE  CASE  TYPE 

System  Analysis 

PRIORITY: 

High 

SOURCE: 

Requirements  Analysis 

PRIMARY  BUSINESS 
ACTOR 

System  Manager 

PRIMARY  SYSTEM 
ACTOR 

OTHER 

PARTICIPATING 

ACTORS: 

Employers 

Recruiters 

Candidates 

DESCRIPTION: 

This  use  case  describes  how  a  System  Manager  can  create  content  for  the 
management  web  portal  as  well  as  control  the  core  content  for  the  entire 
RBAS  site. 

PRE-CONDITION: 

The  System  Manager  is  registered  in  the  Reserve  Billet  Advertisement 

System  and  has  been  assigned  the  appropriate  level  of  access. 

TRIGGER: 

The  System  Manager  creates  site  wide  content  or  management  portal 
settings  in  RBAS. 

TYPICAL  COURSE 

OF  EVENTS: 

Actor  Action 

System  Response 

Step  1 :  The  System  Manager 
logons  to  RBAS. 

Step  2:  The  system  prompts  the  user  to 
select  what  content  they  want  included  in 
the  management  portal  or  site  core  portal. 
The  user  will  be  provided  with  a  list  of 
alternative  to  select  from. 

Step  3 :  The  System  Manager 
selects  the  services  that  he  or 
she  wants  to  populate  the 
management  or  core  site  portal 
with.  When  the  System 

Manager  is  done  selecting 
content  he  or  she  clicks 
“submit”  to  transmit  settings 
back  to  RBAS. 

Step  4:  RBAS  acknowledges  the  request, 
and  updates  the  system  manager’s 
preferences  queue  and  updates  the 
database. 

Step  5:  The  system  sends  a  positive 
response  acknowledging  changes  and 
instructs  user  to  log  on  and  off  to  view 
the  changes. 

ALTERNATE 

COURSES: 

None 

CONCLUSION: 

The  system  manager  creates  the  attributes  for  the  management  and/or  the 
site  core  web  portal. 

POST-CONDITION: 

BUSINESS  RULES 

IMPLEMENTATION 
CONTRAINTS  AND 
SPECIFICATIONS 

ASSUMPTIONS: 

189 


Create  Manager  Portal  Settings  Process  Model 
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Management  Subsystem 


USE  CASE  NAME: 

Review  Management  and  Site  Web 

Portal  Content 

USE  CASE  TYPE 

System  Analysis 

PRIORITY: 

Medium 

SOURCE: 

Requirements  Analysis 

PRIMARY  BUSINESS 
ACTOR 

System  Manager 

PRIMARY  SYSTEM 
ACTOR 

OTHER 

PARTICIPATING 

ACTORS: 

Employer 

Recruiter 

Candidate 

DESCRIPTION: 

This  use  case  describes  how  a  System  Manager  can  review  settings  for  both 
the  Managerial  and  Site  web  portal  for  the  Reserve  Billet  Advertisement 
System. 

PRE-CONDITION: 

The  System  Manager  is  registered  in  the  Reserve  Billet  Advertisement 

System  and  has  been  assigned  the  appropriate  level  of  access. 

TRIGGER: 

The  System  Manager  reviews  Managerial  and/or  Site  web  portal  settings  in 
RBAS. 

TYPICAL  COURSE 

OF  EVENTS: 

Actor  Action 

System  Response 

Step  1 :  The  system  manager 
selects  “view”  Managerial  web 
portal  settings  or  “view”  Site 
web  portal  settings  from  menu 
of  choices. 

Step  2:  The  system  queries  the  database 
for  the  System  Manager’s  current 
settings. 

Step  3:  RBAS  displays  the  queries 
results. 

ALTERNATE 

COURSES: 

SR  Step  3:  If  the  RBAS’s  settings  have  not  been  modified  from  the  default 
values  the  system  displays  an  error  message. 

CONCLUSION: 

The  System  Manager  reviews  either  or  both  the  Managerial  and/or  the  Site 
web  portal  settings. 

POST-CONDITION: 

BUSINESS  RULES 

IMPLEMENTATION 
CONTRAINTS  AND 
SPECIFICATIONS 

ASSUMPTIONS: 

Revieu 

Manager 

/  Managen 

Request  Portal 
Sellings 

lent  Portal  Settings  Process  Model 

Query  For 

Manager 
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Management  Subsystem 


USE  CASE  NAME: 

Update  Personal  Content  for 
Management  and  Site  Portals 

USE  CASE  TYPE 

System  Analysis 

PRIORITY: 

Medium 

SOURCE: 

Requirements  Analysis 

PRIMARY  BUSINESS 
ACTOR 

System  Manager 

PRIMARY  SYSTEM 
ACTOR 

OTHER 

PARTICIPATING 

ACTORS: 

Employer 

Recruiter 

Candidate 

DESCRIPTION: 

This  use  case  describes  how  a  System  Manager  can  update  their 
personalized  web  portal  as  well  as  the  core  portal  attributes  for  the  entire 
Reserve  Billet  Advertisement  System. 

PRE-CONDITION: 

The  System  Manager  is  registered  Reserve  Billet  Advertisement  System  and 
have  been  assigned  the  appropriate  level  of  access. 

TRIGGER: 

The  System  Manager  chooses  to  update  their  personal  web  portal  content 
site  content  in  RBAS. 

TYPICAL  COURSE 

OF  EVENTS: 

Actor  Action 

System  Response 

Step  1 :  The  system  manager 
selects  “update”  portal  settings 
from  menu  of  choices. 

Step  2:  The  system  queries  the  database, 
populates  the  list  of  alternative  with 
current  settings. 

Step  3:  The  system  prompts  the  system 
manager  to  update  their  selections. 

Step  3 :  The  system  manager 
selects  the  services  that  he  or 
she  wants  to  populate  their 
personal  portal  with.  When  the 
user  is  done  modifying  their 
settings  he  or  she  hits  “submit” 
to  transmit  settings  back  to 
RBAS. 

Step  4:  RBAS  acknowledges  the  request, 
and  updates  the  member’s  preferences 
queue  and  updates  the  database. 

Step  5:  The  system  sends  a  positive 
response  acknowledging  the  changes  and 
instructs  user  to  log  on  and  off  to  view 
the  changes. 

ALTERNATE 

COURSES: 

SR  Step  2:  The  system  is  query  results  are  negative. 

SR  Step  3:  The  system  presents  and  error  message  informing  the  candidate 
and  asks  the  user  if  they  would  like  to  personalize  their  portal. 

AA  Step  4:  If  the  System  Manager  provides  a  positive  acknowledgement 
they  proceed  to  step  2  of  the  Create  Personal  Portal  Content.  If  not,  the 
transaction  is  cancelled. 

CONCLUSION: 

The  System  Manager  updates  their  settings  for  their  personalized  web  portal 
or  the  settings  for  the  site  web  portal  are  updated. 

POST-CONDITION: 

BUSINESS  RULES 

IMPLEMENTATION 
CONTRAINTS  AND 
SPECIFICATIONS 

ASSUMPTIONS: 
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Manager  Subsystem 


USE  CASE  NAME: 

Delete  Personal  Content  for 

Management  and  Site  Portals 

USE  CASE  TYPE 

System  Analysis 

PRIORITY: 

Medium 

SOURCE: 

Requirements  Analysis 

PRIMARY  BUSINESS 
ACTOR 

Manager 

PRIMARY  SYSTEM 
ACTOR 

OTHER 

PARTICIPATING 

ACTORS: 

Employer 

Recruiter 

Candidate 

DESCRIPTION: 

This  use  case  describes  how  a  System  Manager  can  delete  settings  for  the 
Management  or  Site  web  portal  for  the  Reserve  Billet  Advertisement 

System. 

PRE-CONDITION: 

The  System  Manager  is  registered  Reserve  Billet  Advertisement  System  and 
has  been  assigned  the  appropriate  level  of  access. 

TRIGGER: 

The  System  Manager  deletes  content  from  either  the  Management  or  Site 
web  portal. 

TYPICAL  COURSE 

OF  EVENTS: 

Actor  Action 

System  Response 

Step  1 :  The  System  Manager 
selects  “delete”  management 
portal  settings  or  “delete”  site 
portal  settings  from  menu  of 
choices. 

Step  2:  The  system  queries  the  database 
for  the  System  Manager’s  current 
settings. 

Step  3:  RBAS  displays  the  query  results 
and  prompts  the  user  to  verify  that  they 
want  to  delete  the  settings. 

Step  4:  The  system  manager 
acknowledges  the  system 
prompt. 

Step  5:  The  system  deletes  the  user’s 
personal  settings  and  restores  the 
system’s  default  settings. 

ALTERNATE 

COURSES: 

SR  Step  3:  RBAS  is  at  the  default  values  of  the  system  therefore  the  System 
Manager  doesn’t  have  any  portal  settings  to  delete. 

SR  Step  4:  The  system  displays  an  error  message  and  transaction  is 
canceled. 

CONCLUSION: 

The  candidate  deletes  personal  web  portal  settings. 

POST-CONDITION: 

BUSINESS  RULES 

IMPLEMENTATION 
CONTRAINTS  AND 
SPECIFICATIONS 

ASSUMPTIONS: 
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Delete  Manager  Portal  Settings  Process  Model 
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Management  Subsystem 


USE  CASE  NAME: 

Generate  Detailed  User  Report 

USE  CASE  TYPE 

System  Analysis 

PRIORITY: 

Medium 

SOURCE: 

Requirements  Analysis 

PRIMARY  BUSINESS 
ACTOR 

System  Manager 

PRIMARY  SYSTEM 
ACTOR 

OTHER 

PARTICIPATING 

ACTORS: 

DESCRIPTION: 

This  Use  Case  describes  how  a  System  Manager  generates  a  detailed  report 
on  an  individual  user. 

PRE-CONDITION: 

System  Manager  has  applied  for  and  received  access  to  the  system  with 
appropriate  permissions. 

TRIGGER: 

System  Manager  identifies  a  user  of  interest  and  queries  the  system  by 
hitting  submit. 

TYPICAL  COURSE 

OF  EVENTS: 

Actor  Action 

System  Response 

Step  1 :  The  System  Manager 
selects  “detailed  user  report” 
from  the  management  portal 
and  clicks  submit. 

Step  2:  System  queries  the  database  for 
the  user  of  interest  and  retrieves  the  data 
requested. 

Step  3:  System  displays  results  to  the 
System  Manager. 

Step  4:  The  system  asks  the  user  if  he  or 
she  wishes  to  view  another  user’s 
information. 

Step  5:  The  System  Manager 
responds  positively  the  user 
clicks  “yes’,  the  system 
manager  selects  another  user 
and  the  process  starts  over  else 
the  transaction  is  complete. 

ALTERNATE 

COURSES: 

SR  Step  3:  The  user  doesn’t  exist  in  the  database  and  a  error  message  is 
displayed. 

AA  Step  4:  The  System  Manager  corrects  the  error  and  resubmits. 

SR  Step  5:  System  verifies  completeness  of  data  entered  into  query. 

SR  Step  6:  If  all  required  information  is  entered,  the  system  performs  the 
query. 

SR  Step  7:  System  displays  results. 

CONCLUSION: 

The  System  Manager  is  presented  with  report  requested. 

POST-CONDITION: 

BUSINESS  RULES 

IMPLEMENTATION 
CONTRAINTS  AND 
SPECIFICATIONS 

ASSUMPTIONS: 

The  System  Manager  has  access  and  the  roles  required  for  use  of  RDOL. 
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Management  Subsystem 


USE  CASE  NAME: 

Generate  System  Usage  Report 

USE  CASE  TYPE 

System  Analysis 

PRIORITY: 

Medium 

SOURCE: 

Requirements  Analysis 

PRIMARY  BUSINESS 
ACTOR 

System  Manager 

PRIMARY  SYSTEM 
ACTOR 

OTHER 

PARTICIPATING 

ACTORS: 

DESCRIPTION: 

This  Use  Case  describes  how  a  System  Manager  generates  a  report  that 
tracks  the  use  of  the  RBAS  system. 

PRE-CONDITION: 

System  Manager  has  applied  for  and  received  access  to  the  system  with 
appropriate  permissions. 

TRIGGER: 

System  queries  the  system  for  use  rates. 

TYPICAL  COURSE 

Actor  Action 

System  Response 

OF  EVENTS: 


Step  1 :  Manager  selects 
“system  usage  report”  from  the 
management  portal  and  clicks 
submit. 


Step  5:  If  the  System  Manager 
responds  positively  the  user 
clicks  “yes’,  the  system 
manager  is  provided  with  a  list 
of  alternatives  and  the  process 
starts  over,  else  the  transaction 
is  complete. 


Step  2:  System  queries  the  database  and 
retrieves  the  data  requested. 


Step  3:  System  displays  results  to  the 
System  Manager. 


Step  4:  The  system  asks  the  user  if  they 
wish  to  generate  another  use. 


ALTERNATE 

COURSES: 


CONCLUSION: 


The  System  Manager  is  presented  with  report  requested. 


POST-CONDITION: 


BUSINESS  RULES 


IMPLEMENTATION 
CONTRAINTS  AND 
SPECIFICATIONS 


ASSUMPTIONS: 


The  System  Manager  has  access  and  the  roles  required  for  use  of  RDOL. 
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Management  Subsystem 


USE  CASE  NAME: 

Generate  User  Overview  Report 

USE  CASE  TYPE 

System  Analysis 

PRIORITY: 

Medium 

SOURCE: 

Requirements  Analysis 

PRIMARY  BUSINESS 
ACTOR 

System  Manager 

PRIMARY  SYSTEM 
ACTOR 

OTHER 

PARTICIPATING 

ACTORS: 

DESCRIPTION: 

This  Use  Case  describes  how  a  System  Manager  generates  a  report  that 
displays  all  the  users  of  a  specific  group  or  category  that  is  registered  in  the 
RBAS  system. 

PRE-CONDITION: 

System  Manager  has  applied  for  and  received  access  to  the  system  with 
appropriate  permissions. 

TRIGGER: 

System  Manager  identifies  a  category  or  group  of  users  of  interest  and 
queries  the  system  by  hitting  submit. 

TYPICAL  COURSE 

OF  EVENTS: 

Actor  Action 

System  Response 

Step  1 :  After  selecting  the 
group  or  category  of  interest  the 
System  Manager  selects  “user 
category  report”  from  the 
management  portal  and  clicks 
submit. 

Step  2:  System  queries  the  database  for 
the  group  or  category  of  users  of  interest 
and  retrieves  the  data  requested. 

Step  3:  System  displays  results  to  the 
System  Manager. 

Step  4:  The  system  asks  the  user  if  he  or 
she  wishes  to  view  another  group  or 
category  of  users. 

Step  5:  If  the  System  Manager 
responds  positively  the  user 
clicks  “yes’,  the  system 
manager  selects  another  group 
or  category  of  users  and  the 
process  starts  over,  else  the 
transaction  is  complete. 

ALTERNATE 

COURSES: 

SR  Step  3:  The  group  or  category  of  users  doesn’t  exist  in  the  database  and 
an  error  message  is  displayed. 

AA  Step  4:  The  System  Manager  corrects  the  error  and  resubmits. 

SR  Step  5:  System  verifies  completeness  of  data  entered  into  query. 

SR  Step  6:  If  all  required  information  is  entered,  the  system  performs  the 
query. 

SR  Step  7:  System  displays  results  to  the  Manager. 

CONCLUSION: 

The  System  Manager  is  presented  with  report  requested. 

POST-CONDITION: 

BUSINESS  RULES 

IMPLEMENTATION 
CONTRAINTS  AND 
SPECIFICATIONS 
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ASSUMPTIONS: 


The  System  Manager  has  access  and  the  roles  required  for  use  of  RDOL. 

User  Report  Process  Model 


All  User  Info  Requested 
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Management  Subsystem 


USE  CASE  NAME: 

Ensure  all  form  input  data  is  valid  and 
complete 

USE  CASE  TYPE 

System  Analysis 

PRIORITY: 

High 

SOURCE: 

System  Requirement 

PRIMARY  BUSINESS 
ACTOR 

System 

PRIMARY  SYSTEM 
ACTOR 

OTHER 

PARTICIPATING 

ACTORS: 

Employer 

Recruiter 

Candidate 

System  Manager 

DESCRIPTION: 

This  Use  Case  describes  how  the  RBAS  system  automatically  checks  all 
input  for  completeness  and  accuracy. 

PRE-CONDITION: 

A  user  has  inputted  information  into  an  input  form  for  RBAS. 

TRIGGER: 

The  Use  Case  is  initiated  when  user  submits  information  via  an  input  form. 

TYPICAL  COURSE 

OF  EVENTS: 

Actor  Action 

System  Response 

Step  1 :  A  user  submits 
information  via  an  input  form 
by  hitting  “submit”. 

Step  2:  The  system  uses  defined  business 
rules  to  verify  that  the  input  submitted  is 
complete  and  accurate.  This  includes 
checking  for  missing  information  as  well 
as  for  incorrectly  formatted  data. 

Step  3:  The  system  acknowledges 
validity  of  input  and  stores  the  data  in  the 
database. 

ALTERNATE 

COURSES: 

SR  Step  3:  All  the  required  information  not  present,  error  message  sent  to 
user. 

AA  Step  4:  The  user  corrects  the  error  and  resubmits. 

Return  to  step  2  of  the  “Typical  Course  of  Events” 

CONCLUSION: 

The  user  submits  complete  and  accurate  data  into  an  input  form 

POST-CONDITION: 

User  is  returned  to  portal  homepage. 

BUSINESS  RULES 

IMPLEMENTATION 
CONTRAINTS  AND 
SPECIFICATIONS 

ASSUMPTIONS: 

User  must  have  access  to  NMCI  compliant  web  browser. 
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Manager  Subsystem 


USE  CASE  NAME: 

Automated  Update  of  Candidate  Table 

USE  CASE  TYPE 

System  Analysis 

PRIORITY: 

Medium 

SOURCE: 

Requirements  Analysis 

PRIMARY  BUSINESS 
ACTOR 

System 

PRIMARY  SYSTEM 
ACTOR 

OTHER 

PARTICIPATING 

ACTORS: 

MCTFS 

DESCRIPTION: 

This  use  case  describes  how  a  candidate’s  personal  information  gets 
populated  from  MCTFS. 

PRE-CONDITION: 

TRIGGER: 

This  event  is  a  temporal  trigger  that  occurs  twice  weekly  (nominally). 

TYPICAL  COURSE 

OF  EVENTS: 

Actor  Action 

System  Response 

Step  1:  Temporal  event  occurs 

Step  1 :  The  system  queries  records  that 
are  currently  registered  in  RBAS. 

Step  2:  Most  recent  MCTFS  data  is  then 
queried  for  those  records. 

Step  3:  System  then  compares  actual 
data  with  updated  data. 

Step  4:  The  two  datasets  are  compared 
for  changes. 

Step  5:  If  system  detects  changes  in  data, 
RBAS  candidate  table  is  updated  with 
new  information. 

ALTERNATE 

COURSES: 

SR  Step  2:  If  MCTFS  is  unavailable  at  runtime,  error  message  will  be 
displayed  to  system  manager. 

CONCLUSION: 

The  candidate  table  information  is  updated. 

POST-CONDITION: 

BUSINESS  RULES 

IMPLEMENTATION 
CONTRAINTS  AND 
SPECIFICATIONS 

ASSUMPTIONS: 

MCTFS  is  functioning  properly. 

204 


Autopopulate  Candidate  Personal  Information  Process  Model 


205 


Management  Subsystem 


USE  CASE  NAME: 

Automated  Update  of  MOS  Table 

USE  CASE  TYPE 

System  Analysis 

PRIORITY: 

Medium 

SOURCE: 

Requirements  Analysis 

PRIMARY  BUSINESS 
ACTOR 

System 

PRIMARY  SYSTEM 
ACTOR 

OTHER 

PARTICIPATING 

ACTORS: 

MCTFS 

DESCRIPTION: 

This  use  case  describes  how  the  MOS  table  gets  populated  from  MCTFS. 

PRE-CONDITION: 

TRIGGER: 

This  event  is  a  temporal  trigger  that  occurs  quarterly  (nominally). 

TYPICAL  COURSE 

OF  EVENTS: 

Actor  Action 

System  Response 

Step  1 :  Temporal  event  occurs 

Step  1 :  The  system  queries  MOS  table 
resident  in  RBAS. 

Step  2:  Most  recent  MCTFS  MOS 
information  is  queried. 

Step  3:  System  then  compares  actual 
data  with  updated  data. 

Step  4:  The  two  datasets  are  compared 
for  changes. 

Step  5:  If  system  detects  changes  in  data, 
RBAS  MOS  table  is  updated  with  new 
information. 

ALTERNATE 

COURSES: 

SR  Step  2:  If  MCTFS  is  unavailable  at  runtime,  error  message  will  be 
displayed  to  system  manager. 

CONCLUSION: 

The  MOS  table  information  is  updated. 

POST-CONDITION: 

BUSINESS  RULES 

IMPLEMENTATION 
CONTRAINTS  AND 
SPECIFICATIONS 

ASSUMPTIONS: 

MCTFS  is  functioning  properly. 
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Management  Subsystem 


USE  CASE  NAME: 

Ensure  that  user  credentials  are  verified 
by  use  of  CAC  or  strong  password 
during  login  process 

USE  CASE  TYPE 

PRIORITY: 

Medium 

System  Analysis 

SOURCE: 

Requirements  Analysis 

PRIMARY  BUSINESS 
ACTOR 

System 

PRIMARY  SYSTEM 
ACTOR 

OTHER 

Employers 

PARTICIPATING 

Recruiters 

ACTORS: 

Candidates 

Managers 

DESCRIPTION: 


This  use  case  describes  the  system  actions  performed  when  a  user  logons  to 
the  system.  Credentials  will  be  verified  with  a  Common  Access  Card 
(CAC)  or  strong  password. 


PRE-CONDITION: 


TRIGGER: 


A  user  attempts  to  logon  to  RBAS. 


TYPICAL  COURSE 
OF  EVENTS: 


Actor  Action 


Step  1  :  User  attempts  to  logon 
to  the  RBAS  system  with  either 
a  Common  Access  Card  (CAC) 
or  Strong  Password. 


Step  3:  User  is  successfully 
logged  on  to  RBAS. 


System  Response 


Step  2:  Credentials  of  user  are  validated. 


ALTERNATE 

COURSES: 


SR  Step  4  :  Incorrect  password  or  invalid  CAC  is  identified  to  user. 

AA  Step  3:  User  reattempts  to  login  with  correct  password/valid  CAC. 


CONCLUSION: 


System  validates  user  for  his/her  credentials. 


POST-CONDITION: 


BUSINESS  RULES 


IMPLEMENTATION 
CONTRAINTS  AND 
SPECIFICATIONS 


ASSUMPTIONS: 


User  Validation  Process  Model 
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,  Requested 
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APPENDIX  E.  EMPLOYER  USE  CASES 


Employer  Subsystem 


USE  CASE  NAME: 

Create  Advertisement 

USE  CASE  TYPE 

System  Analysis 

PRIORITY: 

High 

SOURCE: 

Requirement 

PRIMARY  BUSINESS 
ACTOR: 

Employer 

OTHER 

PARTICIPATING 

ACTORS: 

Candidate 

Recruiter 

DESCRIPTION: 

This  use-case  describes  the  action  of  manually  inputting  a  new 
billet/advertisement  into  the  system  to  be  viewed  by  potential  candidates. 

PRE-CONDITION: 

Employer  must  have  the  proper  roles  to  be  able  to  complete  this  use-case. 

TRIGGER: 

This  use  case  is  initiated  when  an  Employer  with  roles  clicks  “Create 
Advertisement” 

TYPICAL  COURSE 

OF  EVENTS: 

Actor  Action 

System  Response 

Step  1 :  Employer  with  roles 
clicks  “Create  Advertisement” 

Step  2:  Screen  with  blank  advertisement 
template  appears  for  employer  to  enter 
information  about  billet. 

Step  3 :  Employer  completes 
form  and  clicks  “submit”  to 
input  information  into  table. 

Step  4:  Inputs  are  validated  on  client  side 
for  correct  type. 

Step  5:  Inputs  are  added  to  billet  table. 

Step  6:  Employer  receives 
message  that  billet  has  been 
successfully  added. 

Step  7 :  Employer  is  provided 
the  option  to  add  another  billet, 
or  to  return  to  the  main  menu. 

Step  8:  System  generates  email  to  all 
subscribers  with  ties  to  this  billet. 

ALTERNATE 

COURSES: 

On  Step  6,  if  there  is  any  error  in  adding  the  record  to  the  table,  a  message 
will  display  that  billet  was  NOT  added. 

CONCLUSION: 

This  use  case  concludes  when  the  employer  receives  a  confirmation  that  the 
billet  was  successfully  entered. 

POST-CONDITION: 

User  is  returned  to  portal  homepage. 

BUSINESS  RULES 

IMPLEMENTATION 
CONTRAINTS  AND 
SPECIFICATIONS 

ASSUMPTIONS: 

User  must  have  access  to  NMCI  compliant  web  browser. 
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Employer  Subsystem 


USE  CASE  NAME: 

Review  Advertisement 

USE  CASE  TYPE 

System  Analysis 

PRIORITY: 

Medium 

SOURCE: 

Requirement 

PRIMARY  BUSINESS 
ACTOR: 

Employer 

OTHER 

PARTICIPATING 

ACTORS: 

DESCRIPTION: 

This  use-case  describes  the  action  of  reviewing  a  manually  inputted 
billet/advertisement  in  the  system. 

PRE-CONDITION: 

Employer  must  have  the  proper  roles  to  be  able  to  complete  this  use-case. 

TRIGGER: 

This  use  case  is  initiated  when  an  Employer  with  roles  clicks  “Review 
Advertisement” 

TYPICAL  COURSE 

OF  EVENTS: 

Actor  Action 

System  Response 

Step  1 :  Employer  with  roles 
clicks  “Review  Advertisement” 

Step  2:  Screen  with  listing  of  all  current 
advertisements  appears  for  the  employer 
to  select  which  one  to  review. 

Step  3 :  Employer  selects  which 
billet  to  review 

Step  4:  Details  of  selected  billet  are 
displayed. 

Step  5:  Employer  is  given  the  option  to 
“Update”  billet/advertisement  or  return  to 
previous  page. 

ALTERNATE 

COURSES: 

CONCLUSION: 

This  use  case  concludes  when  the  employer  can  view  the  details  of  a 
requested  billet. 

POST-CONDITION: 

User  is  returned  to  portal  homepage. 

BUSINESS  RULES 

IMPLEMENTATION 
CONTRAINTS  AND 
SPECIFICATIONS 

ASSUMPTIONS: 

User  must  have  access  to  NMCI  compliant  web  browser. 

Review  Advertisement  Process  Model 
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Employer  Subsystem 


USE  CASE  NAME: 

Update  Advertisement 

USE  CASE  TYPE 

System  Analysis 

PRIORITY: 

Medium 

SOURCE: 

Requirement 

PRIMARY  BUSINESS 
ACTOR: 

Employer 

OTHER 

PARTICIPATING 

ACTORS: 

Reservist 

Recruiter 

DESCRIPTION: 

This  use-case  describes  the  action  of  updating  a  manually  inputted 
billet/advertisement  in  the  system. 

PRE-CONDITION: 

Employer  must  have  the  proper  roles  to  be  able  to  complete  this  use-case. 

TRIGGER: 

This  use  case  is  initiated  when  an  Employer  with  roles  clicks  “Update 
Advertisement” 

TYPICAL  COURSE 

OF  EVENTS: 

Actor  Action 

System  Response 

Step  1 :  Employer  with  roles 
clicks  “Update  Advertisement” 

Step  2:  Screen  with  listing  of  all  current 
advertisements  appears  for  the  employer 
to  select  which  one  to  update. 

Step  3 :  Employer  selects  which 
billet  to  update. 

Step  4:  System  displays  all  billet 
information  from  billet  table. 

Step  5:  Employer  makes 
necessary  updates  to  billet 
fields. 

Step  6:  System  validates  information  on 
client  side  and  updates  billet  table. 

Step  7 :  Employer  receives 
confirmation  on  screen  that  the 
billet  was  updated. 

Step  8:  System  generates  email  to  all 
subscribers  with  ties  to  this  billet. 

ALTERNATE 

COURSES: 

CONCLUSION: 

This  use  case  concludes  when  the  employer  receives  confirmation  that  the 
billet  being  edited  was  updated. 

POST-CONDITION: 

User  is  returned  to  portal  homepage. 

BUSINESS  RULES 

IMPLEMENTATION 
CONTRAINTS  AND 
SPECIFICATIONS 

ASSUMPTIONS: 

User  must  have  access  to  NMCI  compliant  web  browser. 
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Employer  Subsystem 


USE  CASE  NAME: 

Delete  Advertisement 

USE  CASE  TYPE 

System  Analysis 

PRIORITY: 

Medium 

SOURCE: 

Requirement 

PRIMARY  BUSINESS 
ACTOR: 

Employer 

OTHER 

PARTICIPATING 

ACTORS: 

Reservist 

Recruiter 

DESCRIPTION: 

This  use-case  describes  the  action  of  deleting  a  manually  inputted 
billet/advertisement  from  the  system. 

PRE-CONDITION: 

Employer  must  have  the  proper  roles  to  be  able  to  complete  this  use-case. 

TRIGGER: 

This  use  case  is  initiated  when  an  Employer  with  roles  clicks  “Delete 
Advertisement” 

TYPICAL  COURSE 

OF  EVENTS: 

Actor  Action 

System  Response 

Step  1 :  Employer  with  roles 
clicks  “Delete  Advertisement” 

Step  2:  Screen  with  listing  of  all  current 
advertisements  appears  for  the  employer 
to  select. 

Step  3 :  Employer  selects 
appropriate  “check  boxes”  and 
presses  delete  button. 

Step  4:  Window  asking  “Are  you  sure?” 
you  want  to  delete  the  following  billet(s) 
is  displayed. 

Step  5:  Employer  checks  yes  or 
no. 

Step  6:  Billet(s)  is/are  deleted  from  the 
billet  table. 

Step  7 :  Employer  receives 
message  that  billet(s)  has  been 
successfully  deleted. 

Step  8:  System  generates  email  to  all 
subscribers  with  ties  to  this  billet. 

ALTERNATE 

COURSES: 

CONCLUSION: 

This  use  case  concludes  when  the  employer  receives  a  confirmation  that  the 
billet  was  successfully  deleted. 

POST-CONDITION: 

User  is  returned  to  portal  homepage. 

BUSINESS  RULES 

IMPLEMENTATION 
CONTRAINTS  AND 
SPECIFICATIONS 

ASSUMPTIONS: 

User  must  have  access  to  NMCI  compliant  web  browser. 

Delete  Advertisement  Process  Model 
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Employer  Module 


USE  CASE  NAME: 

Create  Automated  Advertisement 

USE  CASE  TYPE 

System  Analysis 

PRIORITY: 

High 

SOURCE: 

Requirement 

PRIMARY  BUSINESS 
ACTOR: 

Employer  System 

OTHER 

PARTICIPATING 

ACTORS: 

External  Data  Sources  (MCTFS,  TFSMS) 

Recruiter 

Candidate 

DESCRIPTION: 

This  use  case  describes  how  the  system  generates  billet  advertisements 
automatically  by  comparing  MCTFS  O/H  data  versus  T/O  data. 

PRE-CONDITION: 

External  data  sources  (MCTFS/TFSMS)  must  be  functioning  correctly. 

TRIGGER: 

This  use  case  is  initiated  temporally  (weekly)  at  a  specified  time. 

TYPICAL  COURSE 

OF  EVENTS: 

Actor  Action 

System  Response 

Step  1 :  System  initiates 
transaction  at  specified  time  to 
automatically  generate 
advertisements. 

Step  2:  System  queries  MCTFS  for  on 
hand  strength  by  Reporting  Unit  Code 
(RUC). 

Step  3:  System  queries  TFSMS  for  billet 
structure  listing  by  RUC. 

Step  4:  MCTFS  and  TFSMS  data  are 
compared  against  one  another  to 
determine  what  billets  are  vacant,  as  well 
as  calculated  losses  (Pending  EAS, 

Transfer  to  FMCR) 

Step  5:  Automated  Advertisements  are 
generated  for  current/future  vacant 
billets. 

Step  6:  Notification  (emaiFportal)  is 
delivered  to  each  Employer  telling  them 
new  advertisements  have  been  generated. 

Step  7 :  Employer  has  7  days  to 
validate  system  generated 
billets  prior  to  them 
automatically  posting  to  RDOL. 

ALTERNATE 

COURSES: 

Alternatively,  this  report  could  query  data  strictly  based  off  of  Billet 
Identification  Code,  if  it  were  tied  in  MCTFS  to  a  Marine’s  SSN. 

CONCLUSION: 

This  use  case  concludes  when  the  employer  receives  a  confirmation  that  the 
automated  billets  were  successfully  created. 

POST-CONDITION: 

User  is  returned  to  portal  homepage. 

BUSINESS  RULES 

IMPLEMENTATION 
CONTRAINTS  AND 
SPECIFICATIONS 

ASSUMPTIONS: 

User  must  have  access  to  NMCI  compliant  web  browser. 
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Employer  Module 


USE  CASE  NAME: 

Create  subscription  to  automated 
candidate  search  services 

USE  CASE  TYPE 

System  Analysis 

PRIORITY: 

Medium 

SOURCE: 

Requirement 

PRIMARY  BUSINESS 
ACTOR: 

Employer 

OTHER 

PARTICIPATING 

ACTORS: 

Candidate 

DESCRIPTION: 

This  Use  Case  describes  how  an  Employer  can  create  a  subscription  to 
automatically  receive  updates  (email  or  notification  on  portal)  if  new 
candidates  that  fit  his  or  her  criteria  (geo  loc,  dates,  MOS)  have  recently 
registered,  posted  new  or  updated  information  or  deleted  items  from  their 
profile. 

PRE-CONDITION: 

The  employer  is  registered  Reserve  Billet  Advertisement  System  and  has 
been  assigned  the  appropriate  level  of  access. 

TRIGGER: 

This  use  case  is  initiated  when  an  Employer  with  roles  clicks  “Create 
Subscription” 

TYPICAL  COURSE 

OF  EVENTS: 

Actor  Action 

System  Response 

Step  1 :  Employer  with  roles 
clicks  “Create  Subscription” 

Step  2:  Screen  with  subscription  criteria 
(MOS,  GeoLoc,  Dates)  appears  for 
employer  to  select  or  input. 

Step  3 :  Employer  completes 
form  and  clicks  submit. 

Step  4:  The  system  verifies  the 
information. 

Step  5:  If  the  information  is  correct,  the 
system  accepts  the  subscription. 

Step  6:  The  system  places  the  employer 
and  their  search  criteria  in  its 
subscription  queue. 

Step  7:  Leads  are  generated  for 
candidates  that  have  subscribed  to 
employer  search  services. 

Step  8:  The  system  compares  the  criteria 
of  newly  posted,  updated  or  deleted 
candidates  versus  the  criteria  posted  by 
subscribers. 

ALTERNATE 

COURSES: 

CONCLUSION: 

This  use  case  concludes  when  the  employer  receives  a  confirmation  that  the 
subscription  has  been  created  successfully. 

POST-CONDITION: 

User  is  returned  to  portal  homepage. 

BUSINESS  RULES 

IMPLEMENTATION 
CONTRAINTS  AND 
SPECIFICATIONS 

ASSUMPTIONS: 

User  must  have  access  to  NMCI  compliant  web  browser. 
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Employer  Subsystem 


USE  CASE  NAME: 

Review  subscription  to  automated 
candidate  search  services 

USE  CASE  TYPE 

System  Analysis 

PRIORITY: 

Medium 

SOURCE: 

Requirement 

PRIMARY  BUSINESS 
ACTOR: 

Employer 

OTHER 

PARTICIPATING 

ACTORS: 

Candidate 

Recruiter 

DESCRIPTION: 

This  Use  Case  describes  how  an  employer  can  review  their  subscriptions 
without  making  any  modifications  to  them. 

PRE-CONDITION: 

Employer  must  have  the  proper  roles  to  be  able  to  complete  this  use-case. 

TRIGGER: 

This  use  case  is  initiated  when  an  Employer  with  roles  clicks  “Review 
Subscription” 

TYPICAL  COURSE 

OF  EVENTS: 

Actor  Action 

System  Response 

Step  1 :  Employer  with  roles 
clicks  “Review  Subscriptions” 

Step  2:  The  system  will  query  the 
database  to  retrieve  the  employer’s 
subscription  information. 

Step  3:  Once  an  active  record  is  found, 
the  system  will  display  the  retrieved 
subscription  information. 

ALTERNATE 

COURSES: 

SR  Step  3:  The  system  is  unable  to  locate  a  subscription  for  the  employer. 

SR  Step  4:  The  system  displays  an  error  message  that  informs  the  employer 
that  he  or  she  has  no  active  subscriptions. 

CONCLUSION: 

This  use  case  concludes  when  the  employer  can  review  their  current 
subscription(s). 

POST-CONDITION: 

User  is  returned  to  portal  homepage. 

BUSINESS  RULES 

IMPLEMENTATION 
CONTRAINTS  AND 
SPECIFICATIONS 

ASSUMPTIONS: 

User  must  have  access  to  NMCI  compliant  web  browser. 

Review  Subscription  Process  Model 
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Employer  Subsystem 


USE  CASE  NAME: 

Update  subscription  to  automated 
candidate  search  services 

USE  CASE  TYPE 

System  Analysis 

PRIORITY: 

Medium 

SOURCE: 

Requirement 

PRIMARY  BUSINESS 
ACTOR: 

Employer 

OTHER 

PARTICIPATING 

ACTORS: 

Candidate 

Recruiter 

DESCRIPTION: 

This  Use  Case  describes  how  an  employer  can  update  their  active 
subscriptions. 

PRE-CONDITION: 

Employer  must  have  the  proper  roles  to  be  able  to  complete  this  use-case. 

TRIGGER: 

This  use  case  is  initiated  when  an  Employer  with  roles  clicks  “Update 
Subscription” 

TYPICAL  COURSE 

OF  EVENTS: 

Actor  Action 

System  Response 

Step  1 :  Employer  with  roles 
clicks  “Update  Subscriptions” 

Step  2:  The  system  will  query  the 
database  to  retrieve  the  employer’s 
subscription  information. 

Step  3:  Once  an  active  record  is  found, 
the  system  will  prompt  the  employer  to 
verify  if  the  information  retrieved  is  the 
subscription  they  want  to  update. 

Step  4:  The  employer  verifies 
the  information  and 
acknowledges  by  pressing 
continue. 

Step  5:  The  system  then  opens  a 
subscription  edit  window  and  populates 
the  fields  with  the  retrieved  information 
and  prompts  the  user  to  update  the 
subscription. 

Step  6:  The  employer  updates 
the  information  and  hits 
“submit”  when  complete. 

Step  7:  The  system  error  checks  the 
information,  if  the  information  is  correct 
the  update  is  accepted,  acknowledged 
and  the  database  is  updated. 

Step  8:  The  system  places  the  employer 
and  their  search  criteria  in  its 
subscription  queue. 

Step  9:  Leads  are  generated  for 
candidates  that  have  subscribed  to 
employer  search  services. 

Step  10:  The  system  compares  the  billet 
identifiers  of  newly  posted,  updated  or 
deleted  jobs  versus  the  criteria  posted  by 
subscribers. 

Step  11:  If  the  search  criteria  matches,  an 
email  is  generated  and  sent  to  the 
employer  or  his  portal  is  updated,  (which 
ever  method  is  selected) 

ALTERNATE 

COURSES: 

SR  Step  3:  The  system  is  unable  to  locate  a  subscription  for  the  employer. 

222 


SR  Step  4:  The  system  displays  an  error  message  that  informs  the  employer 
that  he  or  she  has  no  active  subscriptions. 

CONCLUSION: 

This  use  case  concludes  when  the  employer  can  review  their  current 
subscription(s). 

POST-CONDITION: 

User  is  returned  to  portal  homepage. 

BUSINESS  RULES 

IMPLEMENTATION 
CONTRAINTS  AND 
SPECIFICATIONS 

ASSUMPTIONS: 

User  must  have  access  to  NMCI  compliant  web  browser. 

Employer  Update  Subscription  Process  Model 
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Employer  Subsystem 


USE  CASE  NAME: 

Delete  subscription  to  automated 
candidate  search  services 

USE  CASE  TYPE 

PRIORITY: 

Medium 

System  Analysis 

SOURCE: 

Requirement 

PRIMARY  BUSINESS 
ACTOR: 

Employer 

OTHER 

PARTICIPATING 

ACTORS: 

Candidate 

Recruiter 

DESCRIPTION: 

This  Use  Case  describes  how  an  Employer  can  delete  an  active  subscription. 

PRE-CONDITION: 

You  must  have  the  proper  roles  to  be  able  to  complete  this  use-case. 

TRIGGER: 

This  use  case  is  initiated  when  an  Employer  with  roles  clicks  “Delete 
Subscription” 

TYPICAL  COURSE 

Actor  Action 

System  Response 

OF  EVENTS: 

Step  1 :  The  employer  selects 
“delete”  subscription  from 
menu  of  choices. 

Step  2:  The  system  will  query  the 
database  to  retrieve  the  employer’s 
subscription  information. 

Step  3:  Once  an  active  record  is  found, 
the  system  will  prompt  the  employer  to 
verify  if  the  information  retrieved  is  the 
subscription  they  want  deleted. 

Step  4:  The  employer  verifies 
the  information  and 
acknowledges  by  pressing 
continue. 

Step  5:  The  system  then  prompts  the 
employer  if  they  are  certain  they  want  to 
cancel  this  subscription. 

Step  6:  The  employer 
acknowledges  his  or  her 
approval  by  clicking  “yes” 

Step  7:  The  system  receives  the  response 
and  deletes  the  subscription  from  the 
database 

Step  8:  A  success  message  is  generated 
and  displayed  to  the  employer. 

ALTERNATE 

COURSES: 

SR  Step  3:  The  system  is  unable  to  locate  a  subscription  for  the  employer. 

SR  Step  4:  The  system  displays  an  error  message  that  informs  the  employer 
that  he  or  she  has  no  active  subscriptions. 

AA  Step  6:  The  employer  declines  to  delete  subscription. 

SR  Step  7:  The  system  acknowledges  the  negative  response  and  deletes  the 
transaction. 

SR  Step  8:  The  system  display  successful  cancellation  message  to  user. 

CONCLUSION: 

This  use  case  concludes  when  the  employer  receives  a  confirmation  that  the 
subscription  was  successfully  deleted. 

POST-CONDITION: 

User  is  returned  to  portal  homepage. 

BUSINESS  RULES 

IMPLEMENTATION 
CONTRAINTS  AND 
SPECIFICATIONS 

ASSUMPTIONS: 

User  must  have  access  to  NMCI  compliant  web  browser. 
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Employer  Delete  Subscription  Process  Model 
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Employer  Subsystem 


USE  CASE  NAME: 

View  current  application  pool 

USE  CASE  TYPE 

System  Analysis 

PRIORITY: 

Low 

SOURCE: 

Requirement 

PRIMARY  BUSINESS 
ACTOR: 

Employer 

OTHER 

PARTICIPATING 

ACTORS: 

Candidate 

DESCRIPTION: 

This  use  case  describes  how  an  employer  can  view  all  leads/ applications  that 
have  been  submitted  for  billets  in  their  purview. 

PRE-CONDITION: 

Billet/Advertisement  must  have  had  at  least  one  application. 

TRIGGER: 

This  use  case  is  initiated  when  an  Employer  with  roles  clicks  “View  current 
applications” 

TYPICAL  COURSE 

OF  EVENTS: 

Actor  Action 

System  Response 

Step  1 :  The  employer  selects 
“applicants”  from  an  active 
advertisement. 

Step  2:  The  system  will  query  the 
database  to  retrieve  the  applicant  queue 
for  the  selected  advertisement. 

Step  3:  The  system  will  display  all 
activity  associated  with  that  particular 
advertisement. 

ALTERNATE 

COURSES: 

CONCLUSION: 

This  use  case  concludes  when  the  employer  can  view  all  current  applications 
that  are  pertinent  to  his/her  BIC/RUC  listings. 

POST-CONDITION: 

User  is  returned  to  portal  homepage. 

BUSINESS  RULES 

IMPLEMENTATION 
CONTRAINTS  AND 
SPECIFICATIONS 

ASSUMPTIONS: 

User  must  have  access  to  NMCI  compliant  web  browser. 

View  Candidate  Pool  Process  Model 
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Employer  Subsystem 


USE  CASE  NAME: 

Verify  validity  of  automated  billet 
generation 

USE  CASE  TYPE 

System  Analysis 

PRIORITY: 

Medium 

SOURCE: 

System  Requirement 

PRIMARY  BUSINESS 
ACTOR 

Employer 

PRIMARY  SYSTEM 
ACTOR 

OTHER 

PARTICIPATING 

ACTORS: 

Recruiter 

Candidate 

DESCRIPTION: 

This  Use  Case  describes  how  Employers  verify  the  billets  generated 
automatically  by  the  RBAS  system. 

PRE-CONDITION: 

The  Employer  is  registered  in  the  Reserve  Billet  Advertisement  System  and 
has  been  assigned  the  appropriate  level  of  access. 

TRIGGER: 

The  Use  Case  is  initiated  when  the  RBAS  system  notifies  the  Employer  that 
new  billets  generated  automatically  are  waiting  in  the  approval  queue. 

TYPICAL  COURSE 

OF  EVENTS: 

Actor  Action 

System  Response 

Step  2:  The  Employer  selects 
“review  new  billets 
advertisements”  from  their 
portal. 

Step  1 :  The  system  sends  an  alert  and  an 
email  to  the  employer  informing  them 
that  new  billets  are  in  the  approval  queue. 

Step  3:  The  Employer  views 
the  new  billet  advertisements  in 
the  queue  for  validity  and 
approves  the  billet  by  selecting 
“accept”  or  by  disapproving 
them  by  selecting  “reject”. 

Step  4:  The  system  publishes  the 
advertisement  if  it  is  accepted  by  the 
reviewing  authority.  If  the  billet  is 
rejected  it  is  forwarded  to  the  RUC 
manager. 

Step  5:  The  system  sends  notifications 
to  all  users  that  have  signed  up  to  receive 
billet  notifications. 

ALTERNATE 

COURSES: 

CONCLUSION: 

The  Employer  approves  advertisements  that  were  generated  automatically 
by  the  system. 

POST-CONDITION: 

User  is  returned  to  portal  homepage. 

BUSINESS  RULES 

IMPLEMENTATION 
CONTRAINTS  AND 
SPECIFICATIONS 

ASSUMPTIONS: 

User  must  have  access  to  NMCI  compliant  web  browser. 
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Employer  Subsystem 


USE  CASE  NAME: 

Manually  search  all  Candidates  by 
avenue  of  interest  (MOS/Dates). 

USE  CASE  TYPE 

System  Analysis 

PRIORITY: 

High 

SOURCE: 

Requirement 

PRIMARY  BUSINESS 
ACTOR: 

Employer 

OTHER 

PARTICIPATING 

ACTORS: 

Candidate 

DESCRIPTION: 

This  Use  Case  describes  how  an  Employer  can  search  for  interested 
Candidates  that  match  their  search  criteria. 

PRE-CONDITION: 

You  must  have  the  proper  roles  to  be  able  to  complete  this  use-case. 

TRIGGER: 

This  use  case  is  initiated  when  an  Employer  with  roles  clicks  “Hire 

Candidate” 

TYPICAL  COURSE 

OF  EVENTS: 

Actor  Action 

System  Response 

Step  1 :  Employer  enters  search 
criteria  into  query  form  and 
clicks  “submit”. 

Step  2:  System  verifies  the  data  entered 
into  search  form. 

Step  3:  If  the  information  is  complete, 
the  system  accepts  the  request  and 
conducts  the  search. 

Step  4:  System  displays  listing  of 
candidates  matching  search  criteria. 

Step  5:  Employer  can  then 
click  on  each  candidate  to  get 
more  details  (resume). 

ALTERNATE 

COURSES: 

CONCLUSION: 

This  use  case  concludes  when  the  employer  inputs  search  criteria  and 
receives  an  accurate  listing  of  candidates  meeting  those  criteria. 

POST-CONDITION: 

User  is  returned  to  portal  homepage. 

BUSINESS  RULES 

IMPLEMENTATION 
CONTRAINTS  AND 
SPECIFICATIONS 

ASSUMPTIONS: 

User  must  have  access  to  NMCI  compliant  web  browser. 

Search  Candidates  Process  Model 
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Employer  Subsystem 


USE  CASE  NAME: 

Hire  Candidate 

USE  CASE  TYPE 

System  Analysis 

PRIORITY: 

Medium 

SOURCE: 

Requirement 

PRIMARY  BUSINESS 
ACTOR: 

Employer 

OTHER 

PARTICIPATING 

ACTORS: 

Candidate 

Recruiter 

DESCRIPTION: 

This  use  case  describes  how  an  employer  selects  a  particular  candidate  for  a 
billet. 

PRE-CONDITION: 

You  must  have  the  proper  roles  to  be  able  to  complete  this  use-case. 

TRIGGER: 

This  use  case  is  initiated  when  an  Employer  with  roles  clicks  “Hire 

Candidate” 

TYPICAL  COURSE 

OF  EVENTS: 

Actor  Action 

System  Response 

Step  1 :  Employer  with  roles 
clicks  “Hire  Candidate” 

Step  2:  Screen  appears  with  listing  of  all 
applicants  for  a  particular  billet. 

Step  3 :  Employer  places  check 
box  next  to  candidate  to  hire. 

Step  4:  Confirmation  (Are  you  sure  you 
want  to  hire  Candidate  XXX  for  BIC 
XXX?). 

Step  5:  Once  approved,  system  sends 
notifications  (email/portal)  to  candidate 
that  was  selected  and  candidates  not 
selected. 

Step  6:  System  generates  notification  to 
all  subscribers  with  ties  to  this  billet. 

ALTERNATE 

COURSES: 

CONCLUSION: 

This  use  case  concludes  when  the  employer  receives  a  confirmation  that 
candidate  was  hired  and  successfully  notified. 

POST-CONDITION: 

User  is  returned  to  portal  homepage. 

BUSINESS  RULES 

IMPLEMENTATION 
CONTRAINTS  AND 
SPECIFICATIONS 

ASSUMPTIONS: 

User  must  have  access  to  NMCI  compliant  web  browser. 
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Employer  Subsystem 


USE  CASE  NAME: 

Reject  Candidate 

USE  CASE  TYPE 

System  Analysis 

PRIORITY: 

Medium 

SOURCE: 

Requirement 

PRIMARY  BUSINESS 
ACTOR: 

Employer 

OTHER 

PARTICIPATING 

ACTORS: 

Candidate 

Recruiter 

DESCRIPTION: 

This  use  case  describes  how  an  employer  rejects  a  particular  candidate  for  a 
billet. 

PRE-CONDITION: 

You  must  have  the  proper  roles  to  be  able  to  complete  this  use-case. 

TRIGGER: 

This  use  case  is  initiated  when  an  Employer  with  roles  clicks  “Hire 

Candidate” 

TYPICAL  COURSE 

OF  EVENTS: 

Actor  Action 

System  Response 

Step  1 :  Employer  with  roles 
clicks  “Hire  Candidate” 

Step  2:  Screen  appears  with  listing  of  all 
applicants  for  a  particular  billet. 

Step  3:  Employer  places  check 
box  next  to  candidate  to  hire. 

Step  4:  Confirmation  (Are  you  sure  you 
want  to  hire  Candidate  XXX  for  BIC 
XXX?). 

Step  5:  Once  approved  system  sends 
notifications  (email/portal)  to  candidate 
that  was  selected  and  candidates  not 
selected. 

Step  6:  System  generates  notification  to 
all  subscribers  with  ties  to  this  billet. 

ALTERNATE 

COURSES: 

This  process  is  conducted  simultaneously  with  “Hire  Candidate”.  Upon  a 
candidate  being  selected  and  hired  for  a  billet,  all  other  candidates  are 
rejected. 

CONCLUSION: 

This  use  case  concludes  when  the  employer  receives  a  confirmation  that 
candidate  was  hired  and  candidates  which  were  not  hired  were  successfully 
notified. 

POST-CONDITION: 

User  is  returned  to  portal  homepage. 

BUSINESS  RULES 

IMPLEMENTATION 
CONTRAINTS  AND 
SPECIFICATIONS 

ASSUMPTIONS: 

User  must  have  access  to  NMCI  compliant  web  browser. 
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Employer  Subsystem 


USE  CASE  NAME: 

Communicate  with  candidate  pool 

USE  CASE  TYPE 

System  Analysis 

PRIORITY: 

Medium 

SOURCE: 

Requirement 

PRIMARY  BUSINESS 
ACTOR: 

Employer 

OTHER 

PARTICIPATING 

ACTORS: 

Candidate 

DESCRIPTION: 

This  use  case  describes  how  an  Employer  can  conduct  mass  communication 
with  all  candidates  applying  for  a  specific  billet. 

PRE-CONDITION: 

Billet  must  have  at  least  one  applicant  to  create  an  applicant  pool 

TRIGGER: 

This  use  case  is  initiated  when  an  Employer  with  roles  clicks  “Contact 
applicant  pool”  for  a  specific  billet. 

TYPICAL  COURSE 

OF  EVENTS: 

Actor  Action 

System  Response 

Step  1 :  The  employer  selects 
“applicants”  from  an  active 
advertisement. 

Step  2:  The  system  will  query  the 
database  to  retrieve  the  applicant  queue 
for  the  selected  advertisement. 

Step  3:  The  employer  selects 
“contact  all  applicants”  for 
specified  billet. 

Step  4:  The  system  will  bring  up  a 
subject  and  free  text  form  box  for 
information  to  be  entered. 

Step  5:  The  employer  enters 
information  into  form  and 
clicks  submit. 

Step  6:  The  system  generates 
notifications/emails  (based  on 
preferences)  passing  information  entered 
by  employer. 

CONCLUSION: 

This  use  case  concludes  when  the  candidate  has  been  notified  (portal/email) 
by  the  employer. 

POST-CONDITION: 

User  is  returned  to  portal  homepage. 

BUSINESS  RULES 

IMPLEMENTATION 
CONTRAINTS  AND 
SPECIFICATIONS 

ASSUMPTIONS: 

User  must  have  access  to  NMCI  compliant  web  browser. 
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Employer  Subsystem 


USE  CASE  NAME: 

Communicate  with  potential 
candidates 

USE  CASE  TYPE 

System  Analysis 

PRIORITY: 

Medium 

SOURCE: 

Requirement 

PRIMARY  BUSINESS 
ACTOR: 

Employer 

OTHER 

PARTICIPATING 

ACTORS: 

Candidate 

DESCRIPTION: 

This  use  case  describes  how  an  Employer  can  conduct  mass  communication 
with  all  candidates  who  might  be  interested  in  a  specific  billet.  (IE:  New 
billet  for  an  0659  opens  up,  employer  can  communicate  with  all  RBAS 
users  with  06XX  MOS.) 

PRE-CONDITION: 

TRIGGER: 

This  use  case  is  initiated  when  an  Employer  with  roles  clicks  “Contact 
candidates”. 

TYPICAL  COURSE 

OF  EVENTS: 

Actor  Action 

System  Response 

Step  1 :  The  employer  selects 
“Contact  candidates”  within 
employer  module. 

Step  2:  The  system  will  display  an 
addressee  block  and  free  text  form  block 
to  input  the  message. 

Step  3:  The  employer  then 
selects  addressees  by  criteria 
(rank,  geo  loc)  and  inputs 
message  in  message  block. 

Step  4:  The  system  transmits  information 
to  addressees. 

CONCLUSION: 

This  use  case  concludes  when  the  candidates  receive  communication  from 
employer. 

POST-CONDITION: 

User  is  returned  to  portal  homepage. 

BUSINESS  RULES 

IMPLEMENTATION 
CONTRAINTS  AND 
SPECIFICATIONS 

ASSUMPTIONS: 

User  must  have  access  to  NMCI  compliant  web  browser. 

Contact  Candidate  Process  Model 
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Employer  Subsystem 


USE  CASE  NAME: 

Create  Employer  Content  for  Portal 

USE  CASE  TYPE 

System  Analysis 

PRIORITY: 

Medium 

SOURCE: 

Requirement 

PRIMARY  BUSINESS 
ACTOR 

Employer 

PRIMARY  SYSTEM 
ACTOR 

OTHER 

PARTICIPATING 

ACTORS: 

DESCRIPTION: 

This  use  case  describes  how  an  Employer  can  create  a  personalized  web 
portal  upon  initial  login  to  the  Reserve  Billet  Advertisement  System. 

PRE-CONDITION: 

The  employer  is  registered  in  the  Reserve  Billet  Advertisement  System  and 
has  been  assigned  the  appropriate  level  of  access. 

TRIGGER: 

The  employer  logs  into  personal  portal  for  the  first  time. 

TYPICAL  COURSE 

OF  EVENTS: 

Actor  Action 

System  Response 

Step  1 :  The  employer  logs  on 
to  RBAS  for  the  first  time. 

Step  2:  The  system  prompts  the 
employer  to  select  what  content  they 
want  to  add  to  their  personal  portal.  The 
user  will  be  provided  with  a  list  of 
alternatives  to  select  from. 

Step  3:  The  employer  selects 
the  services  that  he  or  she  wants 
to  populate  their  personal  portal 
with.  When  the  employer  is 
done  choosing,  he  or  she  hits 
“submit”  to  transmit  settings 
back  to  RBAS. 

Step  4:  RBAS  acknowledges  the  request, 
and  updates  the  employer’s  preferences 
queue  and  updates  the  database. 

Step  5:  The  system  sends  a  positive 
response  acknowledging  changes  and 
instructs  user  to  log  off  and  back  on  to 
view  the  changes. 

ALTERNATE 

COURSES: 

None 

CONCLUSION: 

The  employer  personalizes  their  web  portal. 

POST-CONDITION: 

User  is  returned  to  portal  homepage. 

BUSINESS  RULES 

IMPLEMENTATION 
CONTRAINTS  AND 
SPECIFICATIONS 

ASSUMPTIONS: 

User  must  have  access  to  NMCI  compliant  web  browser. 
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Employer  Create  Portal  Settings  Process  Model 
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Employer  Subsystem 


USE  CASE  NAME: 

Review  Employer  Content  for  Portal 

USE  CASE  TYPE 

System  Analysis 

PRIORITY: 

Medium 

SOURCE: 

Requirement 

PRIMARY  BUSINESS 
ACTOR 

Employer 

PRIMARY  SYSTEM 
ACTOR 

OTHER 

PARTICIPATING 

ACTORS: 

DESCRIPTION: 

This  use  case  describes  how  an  employer  can  review  the  customizable 
information  contained  within  their  personal  web  portal  (ie  RSS  feeds, 
content) 

PRE-CONDITION: 

The  employer  is  registered  in  the  Reserve  Billet  Advertisement  System  and 
has  been  assigned  the  appropriate  level  of  access. 

TRIGGER: 

The  employer  reviews  their  personal  settings  within  their  RBAS  personal 
portal. 

TYPICAL  COURSE 

Actor  Action 

System  Response 

OF  EVENTS: 


Step  1 :  The  employer  selects 
“view”  portal  settings  from 
menu  of  choices. 


Step  2:  The  system  queries  the  database 
for  the  employer’s  currents  settings. 


Step  3:  If  the  employer  has  personal 
settings,  RBAS  displays  the  queries 
results. 


ALTERNATE 

COURSES: 


None 


CONCLUSION: 


The  employer  reviews  their  personal  web  portal  settings. 


POST-CONDITION: 


User  is  returned  to  portal  homepage. 


BUSINESS  RULES 


IMPLEMENTATION 
CONTRAINTS  AND 
SPECIFICATIONS 


ASSUMPTIONS: 


User  must  have  access  to  NMCI  compliant  web  browser. 


Review  Employer  Portal  Settings  Process  Model 
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Employer  Subsystem 


USE  CASE  NAME: 

Update  Employer  Web  Portal  Content 

USE  CASE  TYPE 

System  Analysis 

PRIORITY: 

Medium 

SOURCE: 

Requirement 

PRIMARY  BUSINESS 
ACTOR 

Employer 

PRIMARY  SYSTEM 
ACTOR 

OTHER 

PARTICIPATING 

ACTORS: 

DESCRIPTION: 

This  use  case  describes  how  an  employer  can  update  the  customizable 
information  contained  within  their  personal  web  portal  (ie  RSS  feeds, 
content) 

PRE-CONDITION: 

The  employer  is  registered  in  the  Reserve  Billet  Advertisement  System  and 
has  been  assigned  the  appropriate  level  of  access. 

TRIGGER: 

The  employer  updates  their  personal  settings  within  their  RBAS  personal 
portal. 

TYPICAL  COURSE 

OF  EVENTS: 

Actor  Action 

System  Response 

Step  1 :  The  employer  selects 
“update”  portal  settings  from 
menu  of  choices. 

Step  2:  The  system  queries  the  database, 
populates  the  list  of  alternatives  with 
current  settings. 

Step  3:  The  system  prompts  the 
employer  to  update  their  selections. 

Step  3:  The  employer  selects 
the  services  that  he  or  she  wants 
to  populate  their  personal  portal 
with.  When  the  employer  is 
done  modifying  their  settings 
he  or  she  hits  “submit”  to 
transmit  settings  back  to  RBAS. 

Step  4:  RBAS  acknowledges  the  request, 
and  updates  the  employer’s  preferences 
queue  and  updates  the  database. 

Step  5:  The  system  sends  a  positive 
response  acknowledging  the  changes  and 
instructs  user  to  log  off  and  back  on  to 
view  the  changes. 

ALTERNATE 

COURSES: 

None 

CONCLUSION: 

The  employer  updates  their  personal  web  portal  settings. 

POST-CONDITION: 

User  is  returned  to  portal  homepage. 

BUSINESS  RULES 

IMPLEMENTATION 
CONTRAINTS  AND 
SPECIFICATIONS 

ASSUMPTIONS: 

User  must  have  access  to  NMCI  compliant  web  browser. 
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Update  Employer  Portal  Settings  Process  Model 
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Employer  Subsystem 


USE  CASE  NAME: 

Generate  Advertisement  History 

USE  CASE  TYPE 

System  Analysis 

PRIORITY: 

Medium 

SOURCE: 

Requirement 

PRIMARY  BUSINESS 
ACTOR 

Employer 

PRIMARY  SYSTEM 
ACTOR 

OTHER 

PARTICIPATING 

ACTORS: 

DESCRIPTION: 

This  tise  case  describes  how  an  employer  can  view  a  report  which  displays 
advertisement  history  information  for  all  current  applications. 

PRE-CONDITION: 

The  employer  is  registered  Reserve  Billet  Advertisement  System  and  has 
been  assigned  the  appropriate  level  of  access 

TRIGGER: 

Employer  views  advertisement  history  report. 

TYPICAL  COURSE 

Actor  Action 

System  Response 

OF  EVENTS: 


Step  1:  The  employer  clicks  on 
advertisement  history  report. 


Step  2:  System  queries  information  from 
all  advertisements  pertaining  to  that 
specific  employer. 


Step  3:  System  displays  results  to 
Employer. 


ALTERNATE 

COURSES: 


CONCLUSION: 


The  employer  is  presented  with  report  requested. 


POST-CONDITION: 


User  is  returned  to  portal  homepage. 


BUSINESS  RULES 


IMPLEMENTATION 
CONTRAINTS  AND 
SPECIFICATIONS 


ASSUMPTIONS: 


User  must  have  access  to  NMCI  compliant  web  browser. 


Advertisement  History  Report  Process  Model 
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Employer  Subsystem 


USE  CASE  NAME: 

Generate  Detailed  Advertisement 

Report 

USE  CASE  TYPE 

System  Analysis 

PRIORITY: 

Medium 

SOURCE: 

Requirement 

PRIMARY  BUSINESS 
ACTOR 

Employer 

PRIMARY  SYSTEM 
ACTOR 

OTHER 

PARTICIPATING 

ACTORS: 

DESCRIPTION: 

This  use  case  describes  how  an  employer  can  generate  a  report  which  lists 
the  details  of  all  current  advertisements. 

PRE-CONDITION: 

The  employer  is  registered  Reserve  Billet  Advertisement  System  and  has 
been  assigned  the  appropriate  level  of  access 

TRIGGER: 

Employer  views  detailed  advertisement  report. 

TYPICAL  COURSE 

Actor  Action 

System  Response 

OF  EVENTS: 


Step  1:  The  employer  clicks  on 
detailed  advertisement  report. 


Step  2:  System  queries  information  from 
specific  advertisement. 


Step  3:  System  displays  all  information 
on  specific  billet  to  Employer. 


ALTERNATE 

COURSES: 


CONCLUSION: 


The  employer  is  presented  with  report  requested. 


POST-CONDITION: 


User  is  returned  to  portal  homepage. 


BUSINESS  RULES 


IMPLEMENTATION 
CONTRAINTS  AND 
SPECIFICATIONS 


ASSUMPTIONS: 


User  must  have  access  to  NMCI  compliant  web  browser. 


Detailed  Advertisement  Report  Process  Model 
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Employer  Subsystem 


USE  CASE  NAME: 

Generate  Advertisement  Response 

Report 

USE  CASE  TYPE 

System  Analysis 

PRIORITY: 

Medium 

SOURCE: 

Requirement 

PRIMARY  BUSINESS 
ACTOR 

Employer 

PRIMARY  SYSTEM 
ACTOR 

OTHER 

PARTICIPATING 

ACTORS: 

DESCRIPTION: 

This  use  case  describes  how  an  employer  can  view  a  report  which  displays 
advertisement  response  information  for  all  current  applications. 

PRE-CONDITION: 

The  employer  is  registered  Reserve  Billet  Advertisement  System  and  has 
been  assigned  the  appropriate  level  of  access 

TRIGGER: 

Employer  views  advertisement  history  report. 

TYPICAL  COURSE 

OF  EVENTS: 

Actor  Action 

System  Response 

Step  1 :  The  employer  clicks  on 
advertisement  history  report. 

Step  2:  System  queries  information  from 
all  advertisements  pertaining  to  that 
specific  employer. 

Step  3:  System  displays  results  to 
Employer. 

ALTERNATE 

COURSES: 

CONCLUSION: 

The  employer  is  presented  with  report  requested. 

POST-CONDITION: 

User  is  returned  to  portal  homepage. 

BUSINESS  RULES 

IMPLEMENTATION 
CONTRAINTS  AND 
SPECIFICATIONS 

ASSUMPTIONS: 

User  must  have  access  to  NMCI  compliant  web  browser. 
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Advertisement  Response  Report  Process  Model 


Advertisement 

Billet 

Command 
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Employer  Subsystem 


USE  CASE  NAME: 

Generate  Timed  Report  or  Email  (30- 
14-0-14) 

USE  CASE  TYPE 

System  Analysis 

PRIORITY: 

Medium 

SOURCE: 

Requirement 

PRIMARY  BUSINESS 
ACTOR 

Employer  System 

PRIMARY  SYSTEM 
ACTOR 

OTHER 

PARTICIPATING 

ACTORS: 

Candidate 

Employer 

DESCRIPTION: 

This  use  case  describes  how  the  system  generates  a  temporal  report/email 
which  outlines  the  billets  that  will  expire  soon. 

PRE-CONDITION: 

Billets/ Advertisements  must  be  resident  in  the  system. 

TRIGGER: 

System  generates  temporal  reports. 

TYPICAL  COURSE 

OF  EVENTS: 

Actor  Action 

System  Response 

Step  1 :  System  runs  query  to 
determine  which  billets  will 
expire  within  the  following 
dates  (30,  14,  0,  -14). 

Step  2:  System  generates 
email/notification  to  employers  that  are 
responsible  for  those  particular  billets. 

Step  3:  Notification/Email  is 
received  by  employer. 

Step  4:  System  generates  hyperlink  to 
revalidate  expiring  billets  if  necessary. 

Step  5:  If  billets  are  not  re¬ 
validated,  system  deletes 
billets/advertisements  that  have 
been  expired  for  greater  than  14 
days. 

ALTERNATE 

COURSES: 

CONCLUSION: 

Billets  that  are  within  the  expiration  window  will  be  notified/deleted. 

POST-CONDITION: 

User  is  returned  to  portal  homepage. 

BUSINESS  RULES 

IMPLEMENTATION 
CONTRAINTS  AND 
SPECIFICATIONS 

ASSUMPTIONS: 

User  must  have  access  to  NMCI  compliant  web  browser. 
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Employer  Subsystem 


USE  CASE  NAME: 

Manage  candidate  leads 

USE  CASE  TYPE 

System  Analysis 

PRIORITY: 

Medium 

SOURCE: 

Requirement 

PRIMARY  BUSINESS 
ACTOR: 

Employer 

OTHER 

PARTICIPATING 

ACTORS: 

Candidate 

DESCRIPTION: 

This  Use  Case  describes  how  an  Employer  can  manage  all  leads  that  have 
been  generated  for  advertisements  that  are  included  in  their  purview. 

PRE-CONDITION: 

You  must  have  the  proper  roles  to  be  able  to  complete  this  use-case. 

TRIGGER: 

This  use  case  is  initiated  when  an  Employer  with  roles  clicks  “Manage 

Leads” 

TYPICAL  COURSE 

OF  EVENTS: 

Actor  Action 

System  Response 

Step  1 :  Employer  with  roles 
clicks  “Manage  Leads” 

Step  2:  Screen  with  listing  of  all  current 
leads  appears  for  the  employer  to  select 
which  one  to  manage. 

Step  3:  Employer  clicks  on 
appropriate  lead  to  obtain  all  its 
details. 

Step  4:  System  displays  all  details  of 
specific  lead. 

Step  5:  Employer  is  given  the 
option  to  update/delete  the  lead 
or  return  to  the  Leads  menu. 

ALTERNATE 

COURSES: 

CONCLUSION: 

This  use  case  concludes  when  the  employer  is  successfully  able  to  manage 
advertisement  leads. 

POST-CONDITION: 

User  is  returned  to  portal  homepage. 

BUSINESS  RULES 

IMPLEMENTATION 
CONTRAINTS  AND 
SPECIFICATIONS 

ASSUMPTIONS: 

User  must  have  access  to  NMCI  compliant  web  browser. 

Employer  Manage  Candidate  Leads  Process  Model 
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